From john.coomes at oracle.com  Thu Aug  1 10:50:08 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 17:50:08 +0000
Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b101 for changeset
	a013024b0747
Message-ID: <20130801175011.B261B48529@hg.openjdk.java.net>

Changeset: 528c7e76eaee
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/528c7e76eaee

Added tag jdk8-b101 for changeset a013024b0747

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 10:50:21 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 17:50:21 +0000
Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b101 for changeset
	0a7432f898e5
Message-ID: <20130801175029.D22154852A@hg.openjdk.java.net>

Changeset: b8cd8b101ecb
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/b8cd8b101ecb

Added tag jdk8-b101 for changeset 0a7432f898e5

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 10:50:40 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 17:50:40 +0000
Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b101 for changeset
	60b623a36164
Message-ID: <20130801175047.E92444852B@hg.openjdk.java.net>

Changeset: 988a5f2ac559
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/988a5f2ac559

Added tag jdk8-b101 for changeset 60b623a36164

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 10:51:05 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 17:51:05 +0000
Subject: hg: hsx/hotspot-emb/jdk: Added tag jdk8-b101 for changeset
	690161232823
Message-ID: <20130801175229.5E8224852C@hg.openjdk.java.net>

Changeset: b52a2ecdb803
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b52a2ecdb803

Added tag jdk8-b101 for changeset 690161232823

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 10:53:26 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 17:53:26 +0000
Subject: hg: hsx/hotspot-emb/langtools: Added tag jdk8-b101 for changeset
	0324dbf07b0f
Message-ID: <20130801175341.576D84852D@hg.openjdk.java.net>

Changeset: 4c42fba7b0e7
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/4c42fba7b0e7

Added tag jdk8-b101 for changeset 0324dbf07b0f

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 10:53:51 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 17:53:51 +0000
Subject: hg: hsx/hotspot-emb/nashorn: Added tag jdk8-b101 for changeset
	a302b05d0ee4
Message-ID: <20130801175355.A8F414852E@hg.openjdk.java.net>

Changeset: 573ccf92d646
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/573ccf92d646

Added tag jdk8-b101 for changeset a302b05d0ee4

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 11:07:58 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 18:07:58 +0000
Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b101 for changeset
	a013024b0747
Message-ID: <20130801180800.8072948537@hg.openjdk.java.net>

Changeset: 528c7e76eaee
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/528c7e76eaee

Added tag jdk8-b101 for changeset a013024b0747

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 11:07:50 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 18:07:50 +0000
Subject: hg: hsx/hotspot-rt: Added tag jdk8-b101 for changeset 9f74a220677d
Message-ID: <20130801180750.576EA48536@hg.openjdk.java.net>

Changeset: 5eb3c1dc348f
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/5eb3c1dc348f

Added tag jdk8-b101 for changeset 9f74a220677d

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 11:08:12 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 18:08:12 +0000
Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b101 for changeset
	0a7432f898e5
Message-ID: <20130801180823.B777548538@hg.openjdk.java.net>

Changeset: b8cd8b101ecb
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/b8cd8b101ecb

Added tag jdk8-b101 for changeset 0a7432f898e5

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 11:08:36 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 18:08:36 +0000
Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b101 for changeset
	60b623a36164
Message-ID: <20130801180845.3537748539@hg.openjdk.java.net>

Changeset: 988a5f2ac559
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/988a5f2ac559

Added tag jdk8-b101 for changeset 60b623a36164

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 11:09:03 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 18:09:03 +0000
Subject: hg: hsx/hotspot-rt/jdk: Added tag jdk8-b101 for changeset 690161232823
Message-ID: <20130801181034.7E6634853A@hg.openjdk.java.net>

Changeset: b52a2ecdb803
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b52a2ecdb803

Added tag jdk8-b101 for changeset 690161232823

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 11:11:30 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 18:11:30 +0000
Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b101 for changeset
	0324dbf07b0f
Message-ID: <20130801181147.439684853B@hg.openjdk.java.net>

Changeset: 4c42fba7b0e7
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4c42fba7b0e7

Added tag jdk8-b101 for changeset 0324dbf07b0f

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 11:11:58 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 18:11:58 +0000
Subject: hg: hsx/hotspot-rt/nashorn: Added tag jdk8-b101 for changeset
	a302b05d0ee4
Message-ID: <20130801181202.793494853C@hg.openjdk.java.net>

Changeset: 573ccf92d646
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/573ccf92d646

Added tag jdk8-b101 for changeset a302b05d0ee4

! .hgtags


From john.coomes at oracle.com  Thu Aug  1 10:50:00 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 01 Aug 2013 17:50:00 +0000
Subject: hg: hsx/hotspot-emb: Added tag jdk8-b101 for changeset 9f74a220677d
Message-ID: <20130801175001.08B2548527@hg.openjdk.java.net>

Changeset: 5eb3c1dc348f
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/5eb3c1dc348f

Added tag jdk8-b101 for changeset 9f74a220677d

! .hgtags


From harold.seigel at oracle.com  Thu Aug  1 11:51:18 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 01 Aug 2013 14:51:18 -0400
Subject: Request for review: 7073961 [TESTBUG] closed/runtime/4845371/DBB.java
	failed on solaris 10 x64
Message-ID: <51FAAE26.5030306@oracle.com>

Hi,

Please review this small change to help fix bug 7073961.  This change 
adds a method that enables tests to distinguish between Solaris on Sparc 
and Solaris on X86.

Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_7073961/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_7073961/>

Bug link at: http://bugs.sun.com/view_bug.do?bug_id=7073961

JBB Bug at: https://jbs.oracle.com/bugs/browse/JDK-7073961

Thanks!  Harold

From mikhailo.seledtsov at oracle.com  Thu Aug  1 13:32:37 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Thu, 01 Aug 2013 16:32:37 -0400
Subject: Request for review: 7073961 [TESTBUG]
	closed/runtime/4845371/DBB.java failed on solaris 10 x64
In-Reply-To: <51FAAE26.5030306@oracle.com>
References: <51FAAE26.5030306@oracle.com>
Message-ID: <51FAC5E5.20004@oracle.com>

Looks good.

Misha
(not a reviewer)

On 8/1/2013 2:51 PM, harold seigel wrote:
> Hi,
>
> Please review this small change to help fix bug 7073961.  This change 
> adds a method that enables tests to distinguish between Solaris on 
> Sparc and Solaris on X86.
>
> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_7073961/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_7073961/>
>
> Bug link at: http://bugs.sun.com/view_bug.do?bug_id=7073961
>
> JBB Bug at: https://jbs.oracle.com/bugs/browse/JDK-7073961
>
> Thanks!  Harold


From christian.tornqvist at oracle.com  Thu Aug  1 13:40:55 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 1 Aug 2013 16:40:55 -0400
Subject: RFR(S) 8009585: [TESTBUG] test/runtime/7196045 times out
In-Reply-To: <51F9B074.6080906@oracle.com>
References: <017101ce8977$b563c050$202b40f0$@oracle.com>
	<51F5F396.5030001@oracle.com>
	<016601ce8e2c$4124f790$c36ee6b0$@oracle.com>
	<51F9B074.6080906@oracle.com>
Message-ID: <024f01ce8ef7$6ce81b20$46b85160$@oracle.com>

Hi David,

Somehow that option disappeared from the command line when modifying the
test, I've added that and updated the webrev:

http://cr.openjdk.java.net/~ctornqvi/webrev/8009585/webrev.01/

Thanks,
Christian

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: den 31 juli 2013 20:49
To: Christian Tornqvist
Cc: hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(S) 8009585: [TESTBUG] test/runtime/7196045 times out

On 1/08/2013 6:26 AM, Christian Tornqvist wrote:
> Did a jprt run with both tests (increased the jtreg timeout on the 
> original test for 7196045 to 200 seconds), both reproduced on 30/30 
> targets (all platforms except embedded). Test fails to run on embedded 
> since the counter isn't there. This should be solved by excluding this 
> test on embedded platforms since it's not applicable there.

The test needs to add -XX:+UsePerfData in that case.

David
-----

>
> Thanks,
> Christian
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: den 29 juli 2013 00:46
> To: Christian Tornqvist
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(S) 8009585: [TESTBUG] test/runtime/7196045 times out
>
> On 26/07/2013 6:44 AM, Christian Tornqvist wrote:
>> Small fix for a timeout issue in test/runtime/7196045, the internal 
>> test timeout was set to 120 seconds which is the same default timeout 
>> used by jtreg. Usually meant that jtreg ended up killing the test 
>> before it finished. Added an allocation thread and decreased the heap 
>> size, this has greatly increased the reproduction rate of this test, 
>> reproduces within one second for 20 out of 20 runs. Decreased the run 
>> time of the test from 120 seconds to 10 seconds.
>
> Did you see a similar reproduction rate on all platforms? This test 
> might always trivially pass on slower/smaller devices.
>
> David
> -----
>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~ctornqvi/webrev/8009585/webrev.00/
>>
>> Bug:
>>
>> http://bugs.sun.com/view_bug.do?bug_id=8009585
>>
>> Thanks,
>>
>> Christian
>>
>


From christian.tornqvist at oracle.com  Thu Aug  1 15:37:11 2013
From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com)
Date: Thu, 01 Aug 2013 22:37:11 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets
Message-ID: <20130801223721.847174854B@hg.openjdk.java.net>

Changeset: 9bd314787fad
Author:    mseledtsov
Date:      2013-08-01 22:15 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9bd314787fad

8020614: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Summary: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Reviewed-by: kvn, ctornqvi, dholmes

+ test/testlibrary/OutputAnalyzerReportingTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java

Changeset: c01913206da5
Author:    ctornqvi
Date:      2013-08-01 22:20 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c01913206da5

8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle
Summary: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle
Reviewed-by: coleenp, sspitsyn

! src/share/vm/services/management.cpp

Changeset: 81e0f17ade64
Author:    ctornqvi
Date:      2013-08-01 22:25 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/81e0f17ade64

8009407: runtime/8000968/Test8000968.sh has incorrect check for proper config
Summary: runtime/8000968/Test8000968.sh has incorrect check for proper config
Reviewed-by: coleenp, mseledtsov, sspitsyn, hseigel

- test/runtime/8000968/Test8000968.sh
+ test/runtime/CompressedOops/CompressedKlassPointerAndOops.java


From david.holmes at oracle.com  Thu Aug  1 16:37:17 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 02 Aug 2013 09:37:17 +1000
Subject: RFR(S) 8009585: [TESTBUG] test/runtime/7196045 times out
In-Reply-To: <024f01ce8ef7$6ce81b20$46b85160$@oracle.com>
References: <017101ce8977$b563c050$202b40f0$@oracle.com>
	<51F5F396.5030001@oracle.com>
	<016601ce8e2c$4124f790$c36ee6b0$@oracle.com>
	<51F9B074.6080906@oracle.com>
	<024f01ce8ef7$6ce81b20$46b85160$@oracle.com>
Message-ID: <51FAF12D.8040802@oracle.com>

On 2/08/2013 6:40 AM, Christian Tornqvist wrote:
> Hi David,
>
> Somehow that option disappeared from the command line when modifying the
> test, I've added that and updated the webrev:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8009585/webrev.01/

Thanks for adding it in. I think it was added by the test harness 
previously but it is better to handle this in the test itself.

David

> Thanks,
> Christian
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: den 31 juli 2013 20:49
> To: Christian Tornqvist
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(S) 8009585: [TESTBUG] test/runtime/7196045 times out
>
> On 1/08/2013 6:26 AM, Christian Tornqvist wrote:
>> Did a jprt run with both tests (increased the jtreg timeout on the
>> original test for 7196045 to 200 seconds), both reproduced on 30/30
>> targets (all platforms except embedded). Test fails to run on embedded
>> since the counter isn't there. This should be solved by excluding this
>> test on embedded platforms since it's not applicable there.
>
> The test needs to add -XX:+UsePerfData in that case.
>
> David
> -----
>
>>
>> Thanks,
>> Christian
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: den 29 juli 2013 00:46
>> To: Christian Tornqvist
>> Cc: hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR(S) 8009585: [TESTBUG] test/runtime/7196045 times out
>>
>> On 26/07/2013 6:44 AM, Christian Tornqvist wrote:
>>> Small fix for a timeout issue in test/runtime/7196045, the internal
>>> test timeout was set to 120 seconds which is the same default timeout
>>> used by jtreg. Usually meant that jtreg ended up killing the test
>>> before it finished. Added an allocation thread and decreased the heap
>>> size, this has greatly increased the reproduction rate of this test,
>>> reproduces within one second for 20 out of 20 runs. Decreased the run
>>> time of the test from 120 seconds to 10 seconds.
>>
>> Did you see a similar reproduction rate on all platforms? This test
>> might always trivially pass on slower/smaller devices.
>>
>> David
>> -----
>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8009585/webrev.00/
>>>
>>> Bug:
>>>
>>> http://bugs.sun.com/view_bug.do?bug_id=8009585
>>>
>>> Thanks,
>>>
>>> Christian
>>>
>>
>

From kevin.walls at oracle.com  Fri Aug  2 07:52:22 2013
From: kevin.walls at oracle.com (kevin.walls at oracle.com)
Date: Fri, 02 Aug 2013 14:52:22 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8020943: Memory leak when GCNotifier uses
	create_from_platform_dependent_str()
Message-ID: <20130802145230.1B46848572@hg.openjdk.java.net>

Changeset: 32e3bada0978
Author:    kevinw
Date:      2013-08-02 12:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/32e3bada0978

8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str()
Reviewed-by: mgerdin, fparain, dcubed

! src/share/vm/services/gcNotifier.cpp


From daniel.daugherty at oracle.com  Fri Aug  2 13:28:38 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Fri, 02 Aug 2013 20:28:38 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 23 new changesets
Message-ID: <20130802202930.24E334858B@hg.openjdk.java.net>

Changeset: 9d7b55c8a0c4
Author:    cl
Date:      2013-07-25 03:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9d7b55c8a0c4

Added tag jdk8-b100 for changeset 5787fac72e76

! .hgtags

Changeset: 46487ba40ff2
Author:    amurillo
Date:      2013-07-26 03:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/46487ba40ff2

Merge


Changeset: f6921c876db1
Author:    amurillo
Date:      2013-07-26 03:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f6921c876db1

Added tag hs25-b43 for changeset 46487ba40ff2

! .hgtags

Changeset: e84845884c85
Author:    amurillo
Date:      2013-07-26 04:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e84845884c85

8021566: new hotspot build - hs25-b44
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: d90d1b96b65b
Author:    kvn
Date:      2013-07-26 12:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d90d1b96b65b

8008938: TieredCompilation should be default
Summary: switch on TieredCompilation by default
Reviewed-by: twisti

! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp

Changeset: 0f98cc013b21
Author:    fparain
Date:      2013-07-31 08:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0f98cc013b21

Merge


Changeset: c65045599519
Author:    dholmes
Date:      2013-07-25 21:05 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c65045599519

8021314: minimal1.make needs to force off components not supported by the minimal VM
Reviewed-by: coleenp, bpittore

! make/bsd/makefiles/minimal1.make
! make/linux/makefiles/minimal1.make

Changeset: 078e5eb2e52e
Author:    clucasius
Date:      2013-07-27 17:23 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/078e5eb2e52e

Merge


Changeset: da839a3c5735
Author:    dholmes
Date:      2013-07-31 19:05 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/da839a3c5735

Merge


Changeset: e3c8767c5cf8
Author:    tschatzl
Date:      2013-07-24 10:07 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e3c8767c5cf8

8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build"
Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed
Reviewed-by: brutisso, mgerdin

! test/gc/g1/TestPrintRegionRememberedSetInfo.java

Changeset: 7b06ae405d7b
Author:    jmasa
Date:      2013-07-23 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7b06ae405d7b

6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses
Reviewed-by: rasbold, tschatzl, jmasa
Contributed-by: yamauchi at google.com

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/runtime/globals.hpp

Changeset: fb7010c7c011
Author:    jmasa
Date:      2013-07-25 07:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fb7010c7c011

Merge


Changeset: ca9dedeebdec
Author:    jmasa
Date:      2013-07-25 11:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ca9dedeebdec

6412968: CMS Long initial mark pauses
Reviewed-by: rasbold, tschatzl, jmasa
Contributed-by: yamauchi at google.com

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 8796fd3ac898
Author:    tamao
Date:      2013-07-26 13:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8796fd3ac898

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 313227279a05
Author:    brutisso
Date:      2013-08-01 07:03 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/313227279a05

8021967: Deprecate -XX:DefaultMaxRAMFraction
Reviewed-by: tschatzl, jmasa, kvn, tamao

! src/share/vm/runtime/arguments.cpp
+ test/gc/startup_warnings/TestDefaultMaxRAMFraction.java

Changeset: dae8324fc7d1
Author:    brutisso
Date:      2013-08-01 09:35 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dae8324fc7d1

8021879: G1: G1HeapRegionSize flag value not updated correctly
Reviewed-by: tschatzl, jmasa

! src/share/vm/gc_implementation/g1/heapRegion.cpp
+ test/gc/arguments/TestG1HeapRegionSize.java

Changeset: 8d4ff57af591
Author:    brutisso
Date:      2013-08-01 17:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8d4ff57af591

8022051: G1: Remove some unused G1 flags
Reviewed-by: tschatzl, jmasa

! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 69d0dbb53c78
Author:    tamao
Date:      2013-08-01 17:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/69d0dbb53c78

Merge


Changeset: 7c9885d23744
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7c9885d23744

Added tag jdk8-b101 for changeset f6921c876db1

! .hgtags

Changeset: 530fe88b3b2c
Author:    amurillo
Date:      2013-08-02 02:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/530fe88b3b2c

Merge


Changeset: c4697c1c4484
Author:    amurillo
Date:      2013-08-02 02:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c4697c1c4484

Added tag hs25-b44 for changeset 530fe88b3b2c

! .hgtags

Changeset: 79ce055063e9
Author:    amurillo
Date:      2013-08-02 03:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/79ce055063e9

8022124: new hotspot build - hs25-b45
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: dee4c330acd4
Author:    dcubed
Date:      2013-08-02 08:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dee4c330acd4

Merge

- test/runtime/8000968/Test8000968.sh


From daniel.daugherty at oracle.com  Fri Aug  2 13:29:30 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Fri, 02 Aug 2013 20:29:30 +0000
Subject: hg: hsx/hotspot-rt-gate/hotspot: 23 new changesets
Message-ID: <20130802203043.99A5A4858C@hg.openjdk.java.net>

Changeset: 9d7b55c8a0c4
Author:    cl
Date:      2013-07-25 03:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/9d7b55c8a0c4

Added tag jdk8-b100 for changeset 5787fac72e76

! .hgtags

Changeset: 46487ba40ff2
Author:    amurillo
Date:      2013-07-26 03:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/46487ba40ff2

Merge


Changeset: f6921c876db1
Author:    amurillo
Date:      2013-07-26 03:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/f6921c876db1

Added tag hs25-b43 for changeset 46487ba40ff2

! .hgtags

Changeset: e84845884c85
Author:    amurillo
Date:      2013-07-26 04:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/e84845884c85

8021566: new hotspot build - hs25-b44
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: d90d1b96b65b
Author:    kvn
Date:      2013-07-26 12:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/d90d1b96b65b

8008938: TieredCompilation should be default
Summary: switch on TieredCompilation by default
Reviewed-by: twisti

! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp

Changeset: 0f98cc013b21
Author:    fparain
Date:      2013-07-31 08:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/0f98cc013b21

Merge


Changeset: c65045599519
Author:    dholmes
Date:      2013-07-25 21:05 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/c65045599519

8021314: minimal1.make needs to force off components not supported by the minimal VM
Reviewed-by: coleenp, bpittore

! make/bsd/makefiles/minimal1.make
! make/linux/makefiles/minimal1.make

Changeset: 078e5eb2e52e
Author:    clucasius
Date:      2013-07-27 17:23 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/078e5eb2e52e

Merge


Changeset: da839a3c5735
Author:    dholmes
Date:      2013-07-31 19:05 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/da839a3c5735

Merge


Changeset: e3c8767c5cf8
Author:    tschatzl
Date:      2013-07-24 10:07 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/e3c8767c5cf8

8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build"
Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed
Reviewed-by: brutisso, mgerdin

! test/gc/g1/TestPrintRegionRememberedSetInfo.java

Changeset: 7b06ae405d7b
Author:    jmasa
Date:      2013-07-23 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/7b06ae405d7b

6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses
Reviewed-by: rasbold, tschatzl, jmasa
Contributed-by: yamauchi at google.com

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/runtime/globals.hpp

Changeset: fb7010c7c011
Author:    jmasa
Date:      2013-07-25 07:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/fb7010c7c011

Merge


Changeset: ca9dedeebdec
Author:    jmasa
Date:      2013-07-25 11:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/ca9dedeebdec

6412968: CMS Long initial mark pauses
Reviewed-by: rasbold, tschatzl, jmasa
Contributed-by: yamauchi at google.com

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 8796fd3ac898
Author:    tamao
Date:      2013-07-26 13:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/8796fd3ac898

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 313227279a05
Author:    brutisso
Date:      2013-08-01 07:03 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/313227279a05

8021967: Deprecate -XX:DefaultMaxRAMFraction
Reviewed-by: tschatzl, jmasa, kvn, tamao

! src/share/vm/runtime/arguments.cpp
+ test/gc/startup_warnings/TestDefaultMaxRAMFraction.java

Changeset: dae8324fc7d1
Author:    brutisso
Date:      2013-08-01 09:35 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/dae8324fc7d1

8021879: G1: G1HeapRegionSize flag value not updated correctly
Reviewed-by: tschatzl, jmasa

! src/share/vm/gc_implementation/g1/heapRegion.cpp
+ test/gc/arguments/TestG1HeapRegionSize.java

Changeset: 8d4ff57af591
Author:    brutisso
Date:      2013-08-01 17:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/8d4ff57af591

8022051: G1: Remove some unused G1 flags
Reviewed-by: tschatzl, jmasa

! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 69d0dbb53c78
Author:    tamao
Date:      2013-08-01 17:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/69d0dbb53c78

Merge


Changeset: 7c9885d23744
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/7c9885d23744

Added tag jdk8-b101 for changeset f6921c876db1

! .hgtags

Changeset: 530fe88b3b2c
Author:    amurillo
Date:      2013-08-02 02:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/530fe88b3b2c

Merge


Changeset: c4697c1c4484
Author:    amurillo
Date:      2013-08-02 02:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/c4697c1c4484

Added tag hs25-b44 for changeset 530fe88b3b2c

! .hgtags

Changeset: 79ce055063e9
Author:    amurillo
Date:      2013-08-02 03:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/79ce055063e9

8022124: new hotspot build - hs25-b45
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: dee4c330acd4
Author:    dcubed
Date:      2013-08-02 08:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt-gate/hotspot/rev/dee4c330acd4

Merge

- test/runtime/8000968/Test8000968.sh


From harold.seigel at oracle.com  Fri Aug  2 13:31:55 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 02 Aug 2013 16:31:55 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <51F03ABE.2090002@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com>
Message-ID: <51FC173B.6070205@oracle.com>

Hi,

Please review this updated webrev for bug 8003424: 
http://cr.openjdk.java.net/~hseigel/bug_8003424.2/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>

The updated webrev has a lot of changes from the previous webrev, 
including the following:

    1. Class metaspace information is now output when
    -XX:+PrintCompressedOopsMode is specified.

    2. decode_klass_not_null(Register dst, Register src) no longer
    clobbers R12.

    3. Method using_class_vsm() was renamed to using_class_space().

    4. Type narrowKlass was added and replaces narrowOop, where appropriate.

    5. The Metaspace:: qualifier was removed, where it was unnecessary.

    6. Metaspace::initialize_class_space() was made private.

    7. Method max_heap_for_compressed_oops(), in arguments.cpp, was updated.

Performance tests were run by Jenny using specjvm2008, specjbb2005, and 
specjbb2013.  The results showed no significant performance difference 
in terms of scores and gc behavior.

Additional testing was done on Solaris Sparc and Linux x86 using 
SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.

Please let me know what additional tests should be run.

Thanks!
Harold

On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
> Hi Harold,
>
> > Usually the narrow_klass_base will be 32G and the
> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means that
> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12, unless
> > we do multiple addq(r, narrow_klass_base_shifted()).  Does that make 
> sense?
>
> My bad, I miscalculated. But we have "perfect value" 0x800000000 and I 
> am tempted to use may be bts (bit set) to avoid R12 usage (assuming or 
> with check that class metaspace size < 32Gb).
>
> > Is there one prefix byte per instruction, or just for certain 
> instructions?
>
> "Not all instructions require a REX prefix in 64-bit mode. A prefix is 
> necessary only if an instruction references one of the extended 
> registers or uses a 64-bit operand."
>
> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and =32 
> and big java heap. Recently we got several bugs which indicated that 
> we did not separate cleanly oops and klass pointers en/decoding.
>
> Thanks,
> Vladimir
>
> On 7/24/13 11:35 AM, harold seigel wrote:
>> Hi Vladimir,
>>
>> Thank you for the review!  Please see inline comments.
>>
>> Thanks, Harold
>>
>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>> Nice clean up, Harold
>>>>
>>>> Could you add the size of class metaspace in output with
>>>> PrintCompressedOopsMode (and with verbose). I don't want to 
>>>> remember an
>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>> Will be done in next webrev.
>>>>
>>>> Also it would be nice to print these info line (and compressed oops 
>>>> info
>>>> line) in hs_err files.
>> I filed an enhancement bug for this: 8021264
>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>
>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in x86_64.ad.
>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also note
>>>> that code in .ad file does not check the encoding mode for narrow
>>>> klass/oop so it should be conservative and assume that arithmetic
>>>> instructions are used.
>> OK. Thanks.
>>>>
>>>> If Universe::narrow_klass_shift() == 0 you have klass base below 
>>>> 4Gb so
>>>> the value is 32 bit. You can use it directly in narrow klass
>>>> encoding/decoding without destroying R12.
>>>
>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>> bit is extended so you will get wrong result with address > 2gb).
>> But the base will normally be 32Gb.  So this case won't happen very 
>> often.
>>>
>>> You definitely should not use R12 in decode_klass_not_null(Register
>>> dst, Register src) method where you have free 'dst' register.
>> Will be fixed in next webrev.
>>>
>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>> The idea was to avoid using R12 by using shifted base:
>>>
>>> decode:
>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>     shrq(r, LogKlassAlignmentInBytes);
>>>   }
>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>   shlq(r, LogKlassAlignmentInBytes);
>>> }
>>>
>>> Universe::narrow_klass_base_shifted() is set only if
>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>> (max positive int).
>> Usually the narrow_klass_base will be 32G and the
>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means that
>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12, unless
>> we do multiple addq(r, narrow_klass_base_shifted()).  Does that make 
>> sense?
>>>
>>> And you have general memory reservation problem. At least on Solaris,
>>> as I remember, OS will always try to keep protected 4Kb pages between
>>> different requested memory regions. That is why in jdk7 we first
>>> reserve one huge space and then cut it on java heap, perm gen and
>>> protection page below heap to catch implicit NULL exceptions with
>>> compressed oops.
>>>
>>> So, please, verify that you are getting 'cds_address + cds_total'
>>> address or CompressedKlassPointersBase without CDS and with compressed
>>> oops and with Xmx20Gb.
>> I verifed that we get either cds_address+cds_total as the address, or
>> CompressedKlassPointersBase as the address without CDS on Linux, Windows
>> 7, Mac OS, and Solaris 5.11.  This is true with default heap sizes and
>> -Xmx32G.
>>
>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the desired
>> CDS address for class metaspace regardless of heap size.
>>>
>>>>
>>>> instr_size_for_decode_klass_not_null() is ugly but unfortunately we
>>>> can't do other way. I assume you use max size because depending on
>>>> registers used in instructions you will or will not get prefix byte
>>>> (r8-r15).
>> Is there one prefix byte per instruction, or just for certain 
>> instructions?
>>>>
>>>> I will look on changes in more details may be late.
>>>
>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>> which are not obvious.
>> I changed using_class_vsm() to using_class_space().
>>>
>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this fix for bug 8003424.
>>>>>
>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>> Open bug links at:
>>>>>
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>
>>>>> JBS Bug links at
>>>>>
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>
>>>>>
>>>>> This fix provides support for using compressed klass pointers with 
>>>>> CDS.
>>>>> It also changes the class metaspace allocation on 64-bit platforms 
>>>>> when
>>>>> UseCompressedKlassPointers is true.  Instead of allocating the class
>>>>> metaspace as part of the Java Heap allocation and locating it at the
>>>>> base of that allocation, the metaspace will now be allocated
>>>>> separately,
>>>>> above the Java heap.  This will enable future expansion of the
>>>>> metaspace
>>>>> because it won't be backed up against the Java heap.  If CDS is being
>>>>> used, then the CDS region will be allocated between the Java heap and
>>>>> the metaspace.
>>>>>
>>>>> The new class metaspace allocation code tries to allocate memory at
>>>>> 32G,
>>>>> or above the CDS region, if it is present.  Because of this, encoding
>>>>> and decoding of compressed klass pointers will always require use 
>>>>> of a
>>>>> base register.  So, encoding and decoding of compressed klass 
>>>>> pointers
>>>>> will differ from compressed oops.
>>>>>
>>>>> There are no class metaspace allocation changes if
>>>>> UseCompressedKlassPointers is turned off or if running on a 32-bit
>>>>> platform.
>>>>>
>>>>> The code changes also include some cleanup and will fix bugs 8016729,
>>>>> 8011610, and 8003424.
>>>>>
>>>>>
>>>>> Many of the modules in this webrev contain a lot of changes. Modules
>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were changed to
>>>>> support the new encoding and decoding of compressed klass pointers.
>>>>>
>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>> allocation for metaspace and the CDS region and to determine 
>>>>> compressed
>>>>> klass pointer encoding base and shifting values.
>>>>>
>>>>> Most of the changes to module universe.cpp were to remove code 
>>>>> related
>>>>> to allocating metaspace and remove code that considered compressed
>>>>> klass
>>>>> pointers when determining the compressed oops compression mechanism.
>>>>>
>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as part of a
>>>>> cleanup requested by Coleen.
>>>>>
>>>>>
>>>>> These changes were tested with JCK Lang and VM tests, JTReg tests,
>>>>> JPRT,
>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>> tests.  Most of the test were run with -Xshare:on and -Xshare:off 
>>>>> (with
>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>> 64-Bit
>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS.  JCK tests were
>>>>> run on Solaris x86.
>>>>>
>>>>> The performance impact of these changes is TBD.
>>>>>
>>>>> Thanks, Harold
>>>>>
>>>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130802/3e2153e6/attachment-0001.html 

From christian.tornqvist at oracle.com  Fri Aug  2 15:21:03 2013
From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com)
Date: Fri, 02 Aug 2013 22:21:03 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets
Message-ID: <20130802222112.0ACF8485A1@hg.openjdk.java.net>

Changeset: fa57c8104b76
Author:    ctornqvi
Date:      2013-08-02 18:12 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fa57c8104b76

8009585: test/runtime/7196045 times out
Summary: test/runtime/7196045 times out
Reviewed-by: dholmes, mseledtsov

- test/runtime/7196045/Test7196045.java
+ test/runtime/InternalApi/ThreadCpuTimesDeadlock.java

Changeset: 0f209afdfcf8
Author:    ctornqvi
Date:      2013-08-02 18:26 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0f209afdfcf8

Merge


Changeset: d02de8cac823
Author:    ctornqvi
Date:      2013-08-02 22:34 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d02de8cac823

Merge

- test/runtime/7196045/Test7196045.java


From daniel.daugherty at oracle.com  Fri Aug  2 15:36:07 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 02 Aug 2013 16:36:07 -0600
Subject: code review (round 0) request for VS2010 IDE fix (8016601)
Message-ID: <51FC3457.30003@oracle.com>

Greetings,

I have have a proposed fix for the following bug:

     8016601 Unable to build hsx24 on Windows using project creator and
             Visual Studio
     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016601
     https://jbs.oracle.com/bugs/browse/JDK-8016601

Here are the HSX-25 webrev URLs:

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

Testing:
- JPRT windows_i586 and windows_x64 build and test
- local windows_i586 cmd line builds for:
   {OpenJDK, Oracle} x {Client, Server} VM x {product, debug, fastdebug}
- local windows_i586 VS2010 builds for
   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
fastdebug}
- local windows_x64 VS2010 builds for
   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
fastdebug}
   Thanks to Ron for doing the windows_x64 testing

Gory details are below. As always, comments, questions and
suggestions are welome.

Dan


Gory Details:

Build fixes:
- VS2010 IDE builds are working again; fixes this failure mode:

1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\objectCountEventSender.obj 
: warning LNK4042: object specified more than once; extras ignored
1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\errorReporter.obj 
: warning LNK4042: object specified more than once; extras ignored
1>     Creating library 
D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.lib 
and object 
D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.exp
1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
"public: static void __cdecl 
ObjectCountEventSender::disable_requestable_event(void)" 
(?disable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced in 
function "public: virtual void __thiscall 
VM_GC_SendObjectCountEvent::doit(void)" 
(?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
"public: static void __cdecl 
ObjectCountEventSender::enable_requestable_event(void)" 
(?enable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced in 
function "public: virtual void __thiscall 
VM_GC_SendObjectCountEvent::doit(void)" 
(?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.dll 
: fatal error LNK1120: 2 unresolved externals

- The ProjectCreator tool is modified to support two new options:
   '-relativeAltSrcInclude' and '-altRelativeInclude'. Here's an
   example use of the new options:

       -relativeAltSrcInclude src\closed
       -altRelativeInclude share\vm

   which means config the project with some alternate source files in
   src\closed\share\vm that will replace the corresponding files in
   src\share\vm.

   For example, src\closed\share\vm\utilities\errorReporter.cpp replaces
   src\share\vm\utilities\errorReporter.cpp. In the VS2010 IDE, you'll
   still be able to see src\share\vm\utilities\errorReporter.cpp in the
   project source browser, but the icon will indicate that the file is
   excluded from the project.

   The ProjectCreator tool's file tree walking logic is modified to keep
   track of each alternate source file that is found. If a corresponding
   regular source file is found, then the regular source file is
   excluded from the project in favor of the alternate source version.

- VS2010 cmd line build no longer issue the following linker warnings:

     link.exe @C:\Users\lfoltan\AppData\Local\Temp\nm9B65.tmp
     errorReporter.obj : warning LNK4042: object specified more than 
once; extras ignored
     objectCountEventSender.obj : warning LNK4042: object specified more 
than once; extras ignored

Misc cleanups:

- removed more "core" config support from various makefiles and scripts;
   the "core" config is vestigal and was mostly removed years ago; the
   "core" config is not the same as the "minimalvm" config.
- removed extra references to ${ALTSRC}/share/vm/jfr objects
- added some "AltSrc" versus "OpenJDK" identification to messages where
   files are auto-generated
- added some missing copyright headers


From david.holmes at oracle.com  Sun Aug  4 21:34:10 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Mon, 05 Aug 2013 04:34:10 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 20 new changesets
Message-ID: <20130805043452.980D1485D5@hg.openjdk.java.net>

Changeset: 1b6395189726
Author:    minqi
Date:      2013-07-19 14:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1b6395189726

8012263: ciReplay: gracefully exit & report meaningful error when replay data parsing fails
Summary: find_method could return NULL so need explicitly check if there is error after parse_method, exit on error to avoid crash.
Reviewed-by: kvn, twisti
Contributed-by: yumin.qi at oracle.com

! src/share/vm/ci/ciReplay.cpp

Changeset: 5ad7f8179bf7
Author:    minqi
Date:      2013-07-24 08:04 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5ad7f8179bf7

Merge


Changeset: b6baf306e698
Author:    fparain
Date:      2013-07-26 05:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b6baf306e698

Merge


Changeset: 83ca9dc4564d
Author:    fparain
Date:      2013-07-26 15:24 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/83ca9dc4564d

8019845: Memory leak during class redefinition
Reviewed-by: acorn, jmasa, coleenp, dcubed, mgerdin

! src/share/vm/memory/metaspace.cpp

Changeset: f9ee986a9fea
Author:    ccheung
Date:      2013-07-30 14:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f9ee986a9fea

8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases
Summary: Added checking for gcc and simplified the sig_handler() in the test case
Reviewed-by: dcubed, coleenp, minqi, dlong

! test/runtime/6929067/Test6929067.sh
! test/runtime/7107135/Test7107135.sh
! test/runtime/jsig/Test8017498.sh
! test/runtime/jsig/TestJNI.c

Changeset: 0f98cc013b21
Author:    fparain
Date:      2013-07-31 08:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0f98cc013b21

Merge


Changeset: da839a3c5735
Author:    dholmes
Date:      2013-07-31 19:05 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/da839a3c5735

Merge


Changeset: e3c8767c5cf8
Author:    tschatzl
Date:      2013-07-24 10:07 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e3c8767c5cf8

8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build"
Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed
Reviewed-by: brutisso, mgerdin

! test/gc/g1/TestPrintRegionRememberedSetInfo.java

Changeset: 7b06ae405d7b
Author:    jmasa
Date:      2013-07-23 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7b06ae405d7b

6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses
Reviewed-by: rasbold, tschatzl, jmasa
Contributed-by: yamauchi at google.com

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/runtime/globals.hpp

Changeset: fb7010c7c011
Author:    jmasa
Date:      2013-07-25 07:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/fb7010c7c011

Merge


Changeset: ca9dedeebdec
Author:    jmasa
Date:      2013-07-25 11:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ca9dedeebdec

6412968: CMS Long initial mark pauses
Reviewed-by: rasbold, tschatzl, jmasa
Contributed-by: yamauchi at google.com

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 8796fd3ac898
Author:    tamao
Date:      2013-07-26 13:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8796fd3ac898

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 313227279a05
Author:    brutisso
Date:      2013-08-01 07:03 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/313227279a05

8021967: Deprecate -XX:DefaultMaxRAMFraction
Reviewed-by: tschatzl, jmasa, kvn, tamao

! src/share/vm/runtime/arguments.cpp
+ test/gc/startup_warnings/TestDefaultMaxRAMFraction.java

Changeset: dae8324fc7d1
Author:    brutisso
Date:      2013-08-01 09:35 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/dae8324fc7d1

8021879: G1: G1HeapRegionSize flag value not updated correctly
Reviewed-by: tschatzl, jmasa

! src/share/vm/gc_implementation/g1/heapRegion.cpp
+ test/gc/arguments/TestG1HeapRegionSize.java

Changeset: 8d4ff57af591
Author:    brutisso
Date:      2013-08-01 17:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8d4ff57af591

8022051: G1: Remove some unused G1 flags
Reviewed-by: tschatzl, jmasa

! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 69d0dbb53c78
Author:    tamao
Date:      2013-08-01 17:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/69d0dbb53c78

Merge


Changeset: 7c9885d23744
Author:    cl
Date:      2013-08-01 04:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7c9885d23744

Added tag jdk8-b101 for changeset f6921c876db1

! .hgtags

Changeset: 530fe88b3b2c
Author:    amurillo
Date:      2013-08-02 02:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/530fe88b3b2c

Merge


Changeset: c4697c1c4484
Author:    amurillo
Date:      2013-08-02 02:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c4697c1c4484

Added tag hs25-b44 for changeset 530fe88b3b2c

! .hgtags

Changeset: 79ce055063e9
Author:    amurillo
Date:      2013-08-02 03:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/79ce055063e9

8022124: new hotspot build - hs25-b45
Reviewed-by: jcoomes

! make/hotspot_version


From kevin.walls at oracle.com  Mon Aug  5 04:42:10 2013
From: kevin.walls at oracle.com (kevin.walls at oracle.com)
Date: Mon, 05 Aug 2013 11:42:10 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8021444: SA: ClassDump.run() should not
	ignore existing ClassFilter.
Message-ID: <20130805114212.76C6A485D9@hg.openjdk.java.net>

Changeset: e0379d5ba5d2
Author:    kevinw
Date:      2013-08-05 10:27 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e0379d5ba5d2

8021444: SA: ClassDump.run() should not ignore existing ClassFilter.
Reviewed-by: minqi, poonam

! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java


From stevenschlansker at gmail.com  Sun Aug  4 22:21:10 2013
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Sun, 4 Aug 2013 22:21:10 -0700
Subject: Dismal performance of String.intern()
In-Reply-To: <51B6EDAE.3080300@oracle.com>
References: <E6BC4FB7-59D7-4B51-94FA-FDE9D436AE34@gmail.com>
	<51B6EDAE.3080300@oracle.com>
Message-ID: <20130804222110.3b032f4e@luminol>

On Tue, 11 Jun 2013 10:28:14 +0100
Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 10/06/2013 19:06, Steven Schlansker wrote:
> > Hi core-libs-dev,
> >
> > While doing performance profiling of my application, I discovered
> > that nearly 50% of the time deserializing JSON was spent within
> > String.intern().  I understand that in general interning Strings is
> > not the best approach for things, but I think I have a decent use
> > case -- the value of a certain field is one of a very limited
> > number of valid values (that are not known at compile time, so I
> > cannot use an Enum), and is repeated many millions of times in the
> > JSON stream.
> >
> Have you run with -XX:+PrintStringTableStatistics? Might be
> interesting if you can share the output (it is printed just before
> the VM terminates).
> 
> There are also tuning knobs such as StringTableSize and would be 
> interesting to know if you've experimented with.
> 
> -Alan.

Hi everyone,

Thanks again for your useful advice.  I definitely misjudged the
difficulty and complexity of working with methods that directly bridge
the Java <-> C++ "gap"!  As such, it took me way longer to get to this
than I expected...

That said, I think I have very good results to report.  OpenJDK8 is
already *significantly* better than OpenJDK 7 was, but still can be
better.

Here is the patch I have at the moment:
https://gist.github.com/stevenschlansker/6153643

I used oprofile with oprofile-jit to identify the hot spots in the
benchmark code as being java_lang_String::equals() and
java_lang_String::as_unicode_string.

Both of these methods have hand-written loops that copy or compare
jchar arrays.

The problem is that in -fastdebug or -slowdebug releases, this is
one method call per character (the function is not inlined).  Even in
-release builds, it seems that this is significantly slower than the
libc memcpy() or memcmp() functions which can use SSE4 (or other
related technologies).

My patch adds new methods, char_cmp and char_cpy, which delegate to the
mem* functions instead of using hand-written loops.

The micro-benchmark results are very good for such a small change.

On fastdebug, before:

Benchmark                                          Mode Thr    Cnt
Sec         Mean   Mean error    Units
o.s.b.InternBenchmark.testLongStringChmIntern    sample   1   2819
5        1.780        0.184  msec/op
o.s.b.InternBenchmark.testLongStringJdkIntern    sample   1    343
5       14.571        0.310  msec/op
o.s.b.InternBenchmark.testLongStringNoIntern     sample   1   8712
5        0.526        0.138  msec/op
o.s.b.InternBenchmark.testShortStringChmIntern   sample   1   4427
5        1.133        0.121  msec/op
o.s.b.InternBenchmark.testShortStringJdkIntern   sample   1    603
5        8.319        0.161  msec/op
o.s.b.InternBenchmark.testShortStringNoIntern    sample   1  17185
5        0.274        0.048  msec/op

After:

Benchmark                                          Mode Thr    Cnt
Sec         Mean   Mean error    Units
o.s.b.InternBenchmark.testLongStringChmIntern    sample   1   2898
5        1.812        0.208  msec/op
o.s.b.InternBenchmark.testLongStringJdkIntern    sample   1   1138
5        4.397        0.136  msec/op
o.s.b.InternBenchmark.testLongStringNoIntern     sample   1   9035
5        0.519        0.146  msec/op
o.s.b.InternBenchmark.testShortStringChmIntern   sample   1   4538
5        1.094        0.107  msec/op
o.s.b.InternBenchmark.testShortStringJdkIntern   sample   1   1363
5        3.686        0.100  msec/op
o.s.b.InternBenchmark.testShortStringNoIntern    sample   1  16686
5        0.316        0.081  msec/op

On release, before:

Benchmark                                          Mode Thr    Cnt
Sec         Mean   Mean error    Units
o.s.b.InternBenchmark.testLongStringChmIntern    sample   1   4030
5        1.240        0.002  msec/op
o.s.b.InternBenchmark.testLongStringJdkIntern    sample   1   1024
5        4.894        0.042  msec/op
o.s.b.InternBenchmark.testLongStringNoIntern     sample   1  20000
5        0.185        0.002  msec/op
o.s.b.InternBenchmark.testShortStringChmIntern   sample   1   6143
5        0.814        0.005  msec/op
o.s.b.InternBenchmark.testShortStringJdkIntern   sample   1   1852
5        2.702        0.016  msec/op
o.s.b.InternBenchmark.testShortStringNoIntern    sample   1  20000
5        0.102        0.001  msec/op

After:

Benchmark                                          Mode Thr    Cnt
Sec         Mean   Mean error    Units
o.s.b.InternBenchmark.testLongStringChmIntern    sample   1   4040
5        1.236        0.002  msec/op
o.s.b.InternBenchmark.testLongStringJdkIntern    sample   1   2733
5        1.832        0.010  msec/op
o.s.b.InternBenchmark.testLongStringNoIntern     sample   1  20000
5        0.181        0.002  msec/op
o.s.b.InternBenchmark.testShortStringChmIntern   sample   1   6170
5        0.809        0.001  msec/op
o.s.b.InternBenchmark.testShortStringJdkIntern   sample   1   3577
5        1.396        0.007  msec/op
o.s.b.InternBenchmark.testShortStringNoIntern    sample   1  20000
5        0.102        0.000  msec/op


This is almost a 3.5x improvement on fastdebug builds, and more than a
2.5x improvement on release builds.  It is now only ~50% slower than
ConcurrentHashMap, at least for the low-contention case!  (I did not
benchmark higher numbers of threads thoroughly, but I do not think that
my changes could make that worse...)

Finally, the benchmark code:
https://github.com/stevenschlansker/jvm-intern-benchmark/blob/master/src/main/java/org/sugis/benchmark/InternBenchmark.java

It is not the best ever benchmark, but I'm hopeful that it's "good
enough" to demonstrate the wins I have.  Please let me know if you
believe the benchmark invalidates my conclusions.  It is run with JMH,
as that seems to be the standard way of doing things around here.

Thank you again for your time and input; I am hopeful that I have not
erred terribly :-)

Best,
Steven

From ioi.lam at oracle.com  Mon Aug  5 10:18:38 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 05 Aug 2013 10:18:38 -0700
Subject: RFR (XXS) 8022093 - syntax error near "umpiconninfo_t" -- when
	building on Solaris 10
Message-ID: <51FFDE6E.2090503@oracle.com>

|Please review a very small fix:||
||
||http://cr.openjdk.java.net/~iklam/8022093/solaris_dtrace_002/||
||
||Bug: syntax error near "umpiconninfo_t" -- when building on Solaris 10||
||
||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022093||
||    https://jbs.oracle.com/bugs/browse/JDK-8022093||
||
||Summary of fix:||
||
||    OK -- it's not really fixing the build per-se, but I
     added more error messages to show users possible workarounds.
     Otherwise||it's fairly hard to figure out what to do.
||
||---vvv---||
||Compiling dtrace.d||
||dtrace: failed to compile script dtrace.d: "/usr/lib/dtrace/mpi.d", 
line 68: syntax error near "umpiconninfo_t"||
||*****************************************************************||
||* If you are seeing 'syntax error near "umpiconninfo_t"' on Solaris||
||* 10, try doing 'cd /usr/lib/dtrace && gzip mpi.d' as root, ||
||* or set the environment variable HOTSPOT_DISABLE_DTRACE_PROBES||
||* to disable dtrace probes for this build.||
||*****************************************************************||
||---^^^---||
||
||Tests:||
||
||    JPRT||
||
||Thanks||
||- Ioi||
||
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130805/24a2c75d/attachment.html 

From ioi.lam at oracle.com  Mon Aug  5 11:15:43 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 05 Aug 2013 11:15:43 -0700
Subject: Dismal performance of String.intern()
In-Reply-To: <20130804222110.3b032f4e@luminol>
References: <E6BC4FB7-59D7-4B51-94FA-FDE9D436AE34@gmail.com>
	<51B6EDAE.3080300@oracle.com> <20130804222110.3b032f4e@luminol>
Message-ID: <51FFEBCF.7090408@oracle.com>

Hi Steven,

This looks like a promising patch. If all goes well I can sponsor this 
patch into hotspot-rt.

I have problems building your test. Could you send a stand-alone test 
that can be build with plain JDK (i.e., exclude things like 
com.google.common. and  org.openjdk.jmh)?

Also, I saw that you tested with strings that are the same length as 
UUID, which are 36 chars long:

    2544f85f-1845-42c4-aba1-7a431e6edb99
    eff61458-32f8-45cd-a77d-fddb14951cab
    d685f1a2-0b95-4021-b9b3-b0fb3c02a17f

We do need to handle strings with shorter length, and making calls to 
memcmp() may cause degradation with lots of short strings. Can you add a 
sub-test that tests for strings length <= 4?

I would also recommend running a few non-trivial apps (such as eclipse) 
and dump the interned string table to see the distribution of lengths. I 
know this is a hassle, but it would be a good last step to wrap up your 
work.

Meanwhile, I will try to run our benchmarks (aka "refworkload") to check 
for any performance impact.

Thanks
- Ioi

On 08/04/2013 10:21 PM, Steven Schlansker wrote:
> On Tue, 11 Jun 2013 10:28:14 +0100
> Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>> On 10/06/2013 19:06, Steven Schlansker wrote:
>>> Hi core-libs-dev,
>>>
>>> While doing performance profiling of my application, I discovered
>>> that nearly 50% of the time deserializing JSON was spent within
>>> String.intern().  I understand that in general interning Strings is
>>> not the best approach for things, but I think I have a decent use
>>> case -- the value of a certain field is one of a very limited
>>> number of valid values (that are not known at compile time, so I
>>> cannot use an Enum), and is repeated many millions of times in the
>>> JSON stream.
>>>
>> Have you run with -XX:+PrintStringTableStatistics? Might be
>> interesting if you can share the output (it is printed just before
>> the VM terminates).
>>
>> There are also tuning knobs such as StringTableSize and would be
>> interesting to know if you've experimented with.
>>
>> -Alan.
> Hi everyone,
>
> Thanks again for your useful advice.  I definitely misjudged the
> difficulty and complexity of working with methods that directly bridge
> the Java <-> C++ "gap"!  As such, it took me way longer to get to this
> than I expected...
>
> That said, I think I have very good results to report.  OpenJDK8 is
> already *significantly* better than OpenJDK 7 was, but still can be
> better.
>
> Here is the patch I have at the moment:
> https://gist.github.com/stevenschlansker/6153643
>
> I used oprofile with oprofile-jit to identify the hot spots in the
> benchmark code as being java_lang_String::equals() and
> java_lang_String::as_unicode_string.
>
> Both of these methods have hand-written loops that copy or compare
> jchar arrays.
>
> The problem is that in -fastdebug or -slowdebug releases, this is
> one method call per character (the function is not inlined).  Even in
> -release builds, it seems that this is significantly slower than the
> libc memcpy() or memcmp() functions which can use SSE4 (or other
> related technologies).
>
> My patch adds new methods, char_cmp and char_cpy, which delegate to the
> mem* functions instead of using hand-written loops.
>
> The micro-benchmark results are very good for such a small change.
>
> On fastdebug, before:
>
> Benchmark                                          Mode Thr    Cnt
> Sec         Mean   Mean error    Units
> o.s.b.InternBenchmark.testLongStringChmIntern    sample   1   2819
> 5        1.780        0.184  msec/op
> o.s.b.InternBenchmark.testLongStringJdkIntern    sample   1    343
> 5       14.571        0.310  msec/op
> o.s.b.InternBenchmark.testLongStringNoIntern     sample   1   8712
> 5        0.526        0.138  msec/op
> o.s.b.InternBenchmark.testShortStringChmIntern   sample   1   4427
> 5        1.133        0.121  msec/op
> o.s.b.InternBenchmark.testShortStringJdkIntern   sample   1    603
> 5        8.319        0.161  msec/op
> o.s.b.InternBenchmark.testShortStringNoIntern    sample   1  17185
> 5        0.274        0.048  msec/op
>
> After:
>
> Benchmark                                          Mode Thr    Cnt
> Sec         Mean   Mean error    Units
> o.s.b.InternBenchmark.testLongStringChmIntern    sample   1   2898
> 5        1.812        0.208  msec/op
> o.s.b.InternBenchmark.testLongStringJdkIntern    sample   1   1138
> 5        4.397        0.136  msec/op
> o.s.b.InternBenchmark.testLongStringNoIntern     sample   1   9035
> 5        0.519        0.146  msec/op
> o.s.b.InternBenchmark.testShortStringChmIntern   sample   1   4538
> 5        1.094        0.107  msec/op
> o.s.b.InternBenchmark.testShortStringJdkIntern   sample   1   1363
> 5        3.686        0.100  msec/op
> o.s.b.InternBenchmark.testShortStringNoIntern    sample   1  16686
> 5        0.316        0.081  msec/op
>
> On release, before:
>
> Benchmark                                          Mode Thr    Cnt
> Sec         Mean   Mean error    Units
> o.s.b.InternBenchmark.testLongStringChmIntern    sample   1   4030
> 5        1.240        0.002  msec/op
> o.s.b.InternBenchmark.testLongStringJdkIntern    sample   1   1024
> 5        4.894        0.042  msec/op
> o.s.b.InternBenchmark.testLongStringNoIntern     sample   1  20000
> 5        0.185        0.002  msec/op
> o.s.b.InternBenchmark.testShortStringChmIntern   sample   1   6143
> 5        0.814        0.005  msec/op
> o.s.b.InternBenchmark.testShortStringJdkIntern   sample   1   1852
> 5        2.702        0.016  msec/op
> o.s.b.InternBenchmark.testShortStringNoIntern    sample   1  20000
> 5        0.102        0.001  msec/op
>
> After:
>
> Benchmark                                          Mode Thr    Cnt
> Sec         Mean   Mean error    Units
> o.s.b.InternBenchmark.testLongStringChmIntern    sample   1   4040
> 5        1.236        0.002  msec/op
> o.s.b.InternBenchmark.testLongStringJdkIntern    sample   1   2733
> 5        1.832        0.010  msec/op
> o.s.b.InternBenchmark.testLongStringNoIntern     sample   1  20000
> 5        0.181        0.002  msec/op
> o.s.b.InternBenchmark.testShortStringChmIntern   sample   1   6170
> 5        0.809        0.001  msec/op
> o.s.b.InternBenchmark.testShortStringJdkIntern   sample   1   3577
> 5        1.396        0.007  msec/op
> o.s.b.InternBenchmark.testShortStringNoIntern    sample   1  20000
> 5        0.102        0.000  msec/op
>
>
> This is almost a 3.5x improvement on fastdebug builds, and more than a
> 2.5x improvement on release builds.  It is now only ~50% slower than
> ConcurrentHashMap, at least for the low-contention case!  (I did not
> benchmark higher numbers of threads thoroughly, but I do not think that
> my changes could make that worse...)
>
> Finally, the benchmark code:
> https://github.com/stevenschlansker/jvm-intern-benchmark/blob/master/src/main/java/org/sugis/benchmark/InternBenchmark.java
>
> It is not the best ever benchmark, but I'm hopeful that it's "good
> enough" to demonstrate the wins I have.  Please let me know if you
> believe the benchmark invalidates my conclusions.  It is run with JMH,
> as that seems to be the standard way of doing things around here.
>
> Thank you again for your time and input; I am hopeful that I have not
> erred terribly :-)
>
> Best,
> Steven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130805/ed81e903/attachment-0001.html 

From aleksey.shipilev at oracle.com  Mon Aug  5 11:29:54 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 05 Aug 2013 22:29:54 +0400
Subject: Dismal performance of String.intern()
In-Reply-To: <51FFEBCF.7090408@oracle.com>
References: <E6BC4FB7-59D7-4B51-94FA-FDE9D436AE34@gmail.com>
	<51B6EDAE.3080300@oracle.com> <20130804222110.3b032f4e@luminol>
	<51FFEBCF.7090408@oracle.com>
Message-ID: <51FFEF22.7010409@oracle.com>

On 08/05/2013 10:15 PM, Ioi Lam wrote:
> I have problems building your test. Could you send a stand-alone test
> that can be build with plain JDK (i.e., exclude things like
> com.google.common. and  org.openjdk.jmh)?

I would strongly advise against dropping JMH. Maintaining the benchmark
with JMH is the way to overcome many of the benchmarking pitfalls we
would introduce with custom tests. Depending on Guava is the blocker
though, since we can not have this dependency in OpenJDK before prior
legal review.

-Aleksey.

From aleksey.shipilev at oracle.com  Mon Aug  5 11:43:50 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 05 Aug 2013 22:43:50 +0400
Subject: Dismal performance of String.intern()
In-Reply-To: <20130804222110.3b032f4e@luminol>
References: <E6BC4FB7-59D7-4B51-94FA-FDE9D436AE34@gmail.com>
	<51B6EDAE.3080300@oracle.com> <20130804222110.3b032f4e@luminol>
Message-ID: <51FFF266.5030806@oracle.com>

Hi Steven,

On 08/05/2013 09:21 AM, Steven Schlansker wrote:
> Here is the patch I have at the moment:
> https://gist.github.com/stevenschlansker/6153643

Would you like to make char_cmp() and char_cpy() "inline"? In release,
they can then be compiled straight to memcmp/memcpy.

> This is almost a 3.5x improvement on fastdebug builds, and more than a
> 2.5x improvement on release builds.  It is now only ~50% slower than
> ConcurrentHashMap, at least for the low-contention case!  (I did not
> benchmark higher numbers of threads thoroughly, but I do not think that
> my changes could make that worse...)

The results look good. In fact, I think multi-threaded tests will show
how the StringTable works under contention, and whether the changes you
made are making it worse or better is the open question. (I bet for
"better").

> Finally, the benchmark code:
> https://github.com/stevenschlansker/jvm-intern-benchmark/blob/master/src/main/java/org/sugis/benchmark/InternBenchmark.java
> 
> It is not the best ever benchmark, but I'm hopeful that it's "good
> enough" to demonstrate the wins I have.  Please let me know if you
> believe the benchmark invalidates my conclusions.  It is run with JMH,
> as that seems to be the standard way of doing things around here.

The benchmark is good, actually. You pay for the cost of constructing
the interner, though, but it seems to be the lesser of two evils (i.e.
cleaning the interner is more of the hassle). A few minor nits:

 a) It seems better to design this benchmark this way: prepare the list
of random Strings (Ioi's suggestion to juggle the string lenghts fits
nicely there), feed them to interner, return the interner from the @GMB
method. You will save a lot of blatant allocations like "new
String(buf)" in the hot loop, as well as make loop more unpredictable
(e.g. not relying on successful hoisting).

 b) @BenchmarkMode can float up to class level. Less scaffolding.


-Aleksey.


From coleen.phillimore at oracle.com  Mon Aug  5 12:21:13 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 05 Aug 2013 15:21:13 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <51FC173B.6070205@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
Message-ID: <51FFFB29.9070304@oracle.com>


On 08/02/2013 04:31 PM, harold seigel wrote:
> Hi,
>
> Please review this updated webrev for bug 8003424: 
> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>
> The updated webrev has a lot of changes from the previous webrev, 
> including the following:
>
>     1. Class metaspace information is now output when
>     -XX:+PrintCompressedOopsMode is specified.
>
>     2. decode_klass_not_null(Register dst, Register src) no longer
>     clobbers R12.
>

If decode_klass_not_null(src, dest) doesn't use r12, isn't the size 
calculated by *instr_size_for_decode_klass_not_null* now wrong?   Or is 
this size calculation only valid for the case where you only have one 
register?  Or can this size be a max size?

http://cr.openjdk.java.net/~hseigel/bug_8003424.2/src/share/vm/memory/heap.cpp.frames.html

In this file can you spell out segm_r_aligned to something more 
descriptive - like reserved_segment_alignment, reserved_segments_size, 
committed_segments_size.

http://cr.openjdk.java.net/~hseigel/bug_8003424.2/src/share/vm/memory/metaspace.cpp.udiff.html

*+   if (PrintCompressedOopsMode || (PrintMiscellaneous && Verbose)) {*
*+     gclog_or_tty->print_cr("Narrow klass base: " PTR_FORMAT ", Narrow klass shift: " SIZE_FORMAT,*


I see this conditional comes from universe.cpp but I don't see why this 
should be printed for the OR condition: PrintMiscellaneous && Verbose.

2941 #ifdef _LP64
2942     Universe::set_narrow_klass_base((address)_space_list->current_virtual_space()->bottom()


Put a comment why you do this.  It's so UseCompressedKlassPointers 
decoding "works" while you are creating the shared archive.  The oops 
are thrown away right now so it doesn't matter that the encoded value 
uses a different base during dumping than it will use during 
UseSharedSpaces.   When we share String oops, we'll have to fix this 
code but I don't know how to fix this yet.   Maybe add code that always 
requires that the CDS archive base is the lower of the two bases.   Not 
a problem with your code.

Maybe you should assert that UseCompressedOops and KlassPtrs are set 
here though.

3012   if (using_class_space()) {
3013     _class_space_list = new VirtualSpaceList(rs);
3014   }

This function initialize_class_space() is always called when you are 
using_class_space() so why this conditional?  Shouldn't this also be 
moved to 2917 under where it's called (or above) in the ifdef LP64 since 
it's LP64 only now?

2557   if ((mdtype == Metaspace::ClassType) && !Metaspace::using_class_space()) {
2558     return 0;
2559   }

One way to shorten this expression that appears a few times, is to add 
an inlined overloaded using_class_space(MetadataType).

This looks really good.  I've been through it a few times and I don't 
see any problems, other than these suggestions here.

Thanks!
Coleen

>
>     3. Method using_class_vsm() was renamed to using_class_space().
>
>     4. Type narrowKlass was added and replaces narrowOop, where
>     appropriate.
>
>     5. The Metaspace:: qualifier was removed, where it was unnecessary.
>
>     6. Metaspace::initialize_class_space() was made private.
>
>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>     updated.
>
> Performance tests were run by Jenny using specjvm2008, specjbb2005, 
> and specjbb2013.  The results showed no significant performance 
> difference in terms of scores and gc behavior.
>
> Additional testing was done on Solaris Sparc and Linux x86 using 
> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>
> Please let me know what additional tests should be run.
>
> Thanks!
> Harold
>
> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>> Hi Harold,
>>
>> > Usually the narrow_klass_base will be 32G and the
>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means 
>> that
>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12, 
>> unless
>> > we do multiple addq(r, narrow_klass_base_shifted()).  Does that 
>> make sense?
>>
>> My bad, I miscalculated. But we have "perfect value" 0x800000000 and 
>> I am tempted to use may be bts (bit set) to avoid R12 usage (assuming 
>> or with check that class metaspace size < 32Gb).
>>
>> > Is there one prefix byte per instruction, or just for certain 
>> instructions?
>>
>> "Not all instructions require a REX prefix in 64-bit mode. A prefix 
>> is necessary only if an instruction references one of the extended 
>> registers or uses a 64-bit operand."
>>
>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and =32 
>> and big java heap. Recently we got several bugs which indicated that 
>> we did not separate cleanly oops and klass pointers en/decoding.
>>
>> Thanks,
>> Vladimir
>>
>> On 7/24/13 11:35 AM, harold seigel wrote:
>>> Hi Vladimir,
>>>
>>> Thank you for the review!  Please see inline comments.
>>>
>>> Thanks, Harold
>>>
>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>> Nice clean up, Harold
>>>>>
>>>>> Could you add the size of class metaspace in output with
>>>>> PrintCompressedOopsMode (and with verbose). I don't want to 
>>>>> remember an
>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>> Will be done in next webrev.
>>>>>
>>>>> Also it would be nice to print these info line (and compressed 
>>>>> oops info
>>>>> line) in hs_err files.
>>> I filed an enhancement bug for this: 8021264
>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>
>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in 
>>>>> x86_64.ad.
>>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also note
>>>>> that code in .ad file does not check the encoding mode for narrow
>>>>> klass/oop so it should be conservative and assume that arithmetic
>>>>> instructions are used.
>>> OK. Thanks.
>>>>>
>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below 
>>>>> 4Gb so
>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>> encoding/decoding without destroying R12.
>>>>
>>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>>> bit is extended so you will get wrong result with address > 2gb).
>>> But the base will normally be 32Gb.  So this case won't happen very 
>>> often.
>>>>
>>>> You definitely should not use R12 in decode_klass_not_null(Register
>>>> dst, Register src) method where you have free 'dst' register.
>>> Will be fixed in next webrev.
>>>>
>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>>> The idea was to avoid using R12 by using shifted base:
>>>>
>>>> decode:
>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>   }
>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>> }
>>>>
>>>> Universe::narrow_klass_base_shifted() is set only if
>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>>> (max positive int).
>>> Usually the narrow_klass_base will be 32G and the
>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means that
>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12, unless
>>> we do multiple addq(r, narrow_klass_base_shifted()).  Does that make 
>>> sense?
>>>>
>>>> And you have general memory reservation problem. At least on Solaris,
>>>> as I remember, OS will always try to keep protected 4Kb pages between
>>>> different requested memory regions. That is why in jdk7 we first
>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>> protection page below heap to catch implicit NULL exceptions with
>>>> compressed oops.
>>>>
>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>> address or CompressedKlassPointersBase without CDS and with compressed
>>>> oops and with Xmx20Gb.
>>> I verifed that we get either cds_address+cds_total as the address, or
>>> CompressedKlassPointersBase as the address without CDS on Linux, 
>>> Windows
>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap sizes and
>>> -Xmx32G.
>>>
>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the desired
>>> CDS address for class metaspace regardless of heap size.
>>>>
>>>>>
>>>>> instr_size_for_decode_klass_not_null() is ugly but unfortunately we
>>>>> can't do other way. I assume you use max size because depending on
>>>>> registers used in instructions you will or will not get prefix byte
>>>>> (r8-r15).
>>> Is there one prefix byte per instruction, or just for certain 
>>> instructions?
>>>>>
>>>>> I will look on changes in more details may be late.
>>>>
>>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>>> which are not obvious.
>>> I changed using_class_vsm() to using_class_space().
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this fix for bug 8003424.
>>>>>>
>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>> Open bug links at:
>>>>>>
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>
>>>>>> JBS Bug links at
>>>>>>
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>
>>>>>>
>>>>>> This fix provides support for using compressed klass pointers 
>>>>>> with CDS.
>>>>>> It also changes the class metaspace allocation on 64-bit 
>>>>>> platforms when
>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the class
>>>>>> metaspace as part of the Java Heap allocation and locating it at the
>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>> separately,
>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>> metaspace
>>>>>> because it won't be backed up against the Java heap.  If CDS is 
>>>>>> being
>>>>>> used, then the CDS region will be allocated between the Java heap 
>>>>>> and
>>>>>> the metaspace.
>>>>>>
>>>>>> The new class metaspace allocation code tries to allocate memory at
>>>>>> 32G,
>>>>>> or above the CDS region, if it is present.  Because of this, 
>>>>>> encoding
>>>>>> and decoding of compressed klass pointers will always require use 
>>>>>> of a
>>>>>> base register.  So, encoding and decoding of compressed klass 
>>>>>> pointers
>>>>>> will differ from compressed oops.
>>>>>>
>>>>>> There are no class metaspace allocation changes if
>>>>>> UseCompressedKlassPointers is turned off or if running on a 32-bit
>>>>>> platform.
>>>>>>
>>>>>> The code changes also include some cleanup and will fix bugs 
>>>>>> 8016729,
>>>>>> 8011610, and 8003424.
>>>>>>
>>>>>>
>>>>>> Many of the modules in this webrev contain a lot of changes. Modules
>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were changed to
>>>>>> support the new encoding and decoding of compressed klass pointers.
>>>>>>
>>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>>> allocation for metaspace and the CDS region and to determine 
>>>>>> compressed
>>>>>> klass pointer encoding base and shifting values.
>>>>>>
>>>>>> Most of the changes to module universe.cpp were to remove code 
>>>>>> related
>>>>>> to allocating metaspace and remove code that considered compressed
>>>>>> klass
>>>>>> pointers when determining the compressed oops compression mechanism.
>>>>>>
>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as part 
>>>>>> of a
>>>>>> cleanup requested by Coleen.
>>>>>>
>>>>>>
>>>>>> These changes were tested with JCK Lang and VM tests, JTReg tests,
>>>>>> JPRT,
>>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>>> tests.  Most of the test were run with -Xshare:on and -Xshare:off 
>>>>>> (with
>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>>> 64-Bit
>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests were
>>>>>> run on Solaris x86.
>>>>>>
>>>>>> The performance impact of these changes is TBD.
>>>>>>
>>>>>> Thanks, Harold
>>>>>>
>>>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130805/6915d2e3/attachment-0001.html 

From serguei.spitsyn at oracle.com  Mon Aug  5 12:39:13 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 05 Aug 2013 12:39:13 -0700
Subject: RFR (XXS) 8022093 - syntax error near "umpiconninfo_t" -- when
	building on Solaris 10
In-Reply-To: <51FFDE6E.2090503@oracle.com>
References: <51FFDE6E.2090503@oracle.com>
Message-ID: <51FFFF61.5070409@oracle.com>

The fix is good.
I guess, granting the DTrace permissions on a build machine would be 
another workaround.
Probably, there is no big need to say it in the error message explicitly.

Thanks,
Serguei


On 8/5/13 10:18 AM, Ioi Lam wrote:
> |Please review a very small fix:||
> ||
> ||http://cr.openjdk.java.net/~iklam/8022093/solaris_dtrace_002/||
> ||
> ||Bug: syntax error near "umpiconninfo_t" -- when building on Solaris 10||
> ||
> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022093||
> ||https://jbs.oracle.com/bugs/browse/JDK-8022093||
> ||
> ||Summary of fix:||
> ||
> ||    OK -- it's not really fixing the build per-se, but I
>     added more error messages to show users possible workarounds.
>     Otherwise||it's fairly hard to figure out what to do.
> ||
> ||---vvv---||
> ||Compiling dtrace.d||
> ||dtrace: failed to compile script dtrace.d: "/usr/lib/dtrace/mpi.d", 
> line 68: syntax error near "umpiconninfo_t"||
> ||*****************************************************************||
> ||* If you are seeing 'syntax error near "umpiconninfo_t"' on Solaris||
> ||* 10, try doing 'cd /usr/lib/dtrace && gzip mpi.d' as root, ||
> ||* or set the environment variable HOTSPOT_DISABLE_DTRACE_PROBES||
> ||* to disable dtrace probes for this build.||
> ||*****************************************************************||
> ||---^^^---||
> ||
> ||Tests:||
> ||
> ||    JPRT||
> ||
> ||Thanks||
> ||- Ioi||
> ||
> | 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130805/414e0173/attachment.html 

From harold.seigel at oracle.com  Mon Aug  5 13:45:59 2013
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Mon, 05 Aug 2013 20:45:59 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130805204607.A1E4E485EA@hg.openjdk.java.net>

Changeset: b67604b59546
Author:    hseigel
Date:      2013-08-04 16:30 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b67604b59546

7073961: [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 X65
Summary: Added a x86 64-bit Solaris shared library and rewrote test in Java
Reviewed-by: dholmes, ctornqvi

! test/testlibrary/com/oracle/java/testlibrary/Platform.java

Changeset: 9064e3a19525
Author:    hseigel
Date:      2013-08-05 08:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9064e3a19525

Merge

- test/runtime/7196045/Test7196045.java
- test/runtime/8000968/Test8000968.sh


From vladimir.kozlov at oracle.com  Mon Aug  5 15:59:52 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 05 Aug 2013 15:59:52 -0700
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <51FC173B.6070205@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
Message-ID: <52002E68.6080901@oracle.com>

Harold,

I don't like to have two versions of reinit_heapbase() method. Can you 
modify the original one by checking (Universe::heap() != NULL)?

Note, on SPARC set() could generate up to 8 instructions to load 64-bit 
constant into register. So I am not sure that it will be faster than load.

sparc MacroAssembler::decode_klass_not_null(Register src, Register dst) 
should be modified to not use G6 when narrow_klass_shift() == 0.

x86 MacroAssembler::encode_klass_not_null(Register dst, Register src) 
also should be modified to not use R12 when dst != src by using 
mov64(dst, base) + negq(dst) + addq(dst, src) instructions.

Replace next leaq() with addq(dst, src) (address expressions use adr 
module in cpu which could be bottleneck):

5135     } else {
5136       leaq(dst, Address(dst, src, Address::times_1, 0));


I can't find where in CDS you store information about compressed klass 
pointers and compressed oops parameters which were used during dump?
How you verify that correct parameters/flags are ussed when such CDS is 
used later?

Could you add more explanation in the comment why next method returns 
'false' if DumpSharedSpaces is 'true'? From first glance it contradicts 
to the bug's synopsis:

+  // Return TRUE only if UseCompressedKlassPointers is True and 
DumpSharedSpaces is False.
+  static bool using_class_space() {
+    return NOT_LP64(false) LP64_ONLY(UseCompressedKlassPointers && 
!DumpSharedSpaces);
+  }

Could you move set_narrow_klass_base_and_shift() near 
can_use_cds_with_metaspace_addr() to use one #ifdef LP64?

set_narrow_klass_base_and_shift() and can_use_cds_with_metaspace_addr() 
have the same code for UseSharedSpaces. It would be nice to have only 
one copy. Call can_use_cds_with_metaspace_addr() from 
set_narrow_klass_base_and_shift() ?

I see that you unconditionally set comp klass ptr base and shift for 
DumpSharedSpaces. Should you do the check similar to 
can_use_cds_with_metaspace_addr() to find if you can do that? You don't 
even check UseCompressedKlassPointers.

Why you have next limitation? What if coop can't be used because of big 
heap?:

+     // UseCompressedOops and UseCompressedKlassPointers must be on for 
UseSharedSpaces.
+     if (!UseCompressedOops || !UseCompressedKlassPointers) {
+       no_shared_spaces();

Could you move UseCompressedKlassPointers code in arguments.cpp into 
separate method similar to set_use_compressed_oops()?

About new tests.
The first test in CDSCompressedKPtrsError misses -XX:+UseCompressedOops 
flag.

Could you also test cross flags combinations?:

-XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
-XX:+UseCompressedKlassPointers -XX:-UseCompressedOops

It would be nice to have test to check ClassMetaspaceSize value range. 
You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint or 
maxuint.


About code style, indention. We align next line to corresponding part of 
previous line if we need to split a line. And sometimes it is better to 
keep one long line. I understand some of them were before your changes 
but, please, clean up at lest ones you touched.

Cases in metaspace.cpp:

2263   assert(raw_word_size >= min_size,
2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<" 
SIZE_FORMAT, word_size, min_size));


2485   if (Metaspace::using_class_space() &&
2486     (Metaspace::class_space_list() != NULL)) {


2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
2575                       (Metaspace::using_class_space() ?
2576 
Metaspace::class_space_list()->virtual_space_total() : 0) :
2577                       Metaspace::space_list()->virtual_space_total();


2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) " 
SIZE_FORMAT ", "
2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT ", "
2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT ", "
2697                            "large count " SIZE_FORMAT,
2698              cls_specialized_count, cls_specialized_waste,
2699              cls_small_count, cls_small_waste,
2700              cls_medium_count, cls_medium_waste, cls_humongous_count);


2872       while (!metaspace_rs.is_reserved() && (addr + 1*G > addr) &&
2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {


2889         vm_exit_during_initialization(err_msg(
2890           "Could not allocate metaspace: %d bytes",
2891           class_metaspace_size()));


3107     return using_class_space() ?
3108       class_vsm()->sum_used_in_chunks_in_use() : 0;


3157     if (is_class && using_class_space()) {
3158        class_vsm()->deallocate(ptr, word_size);


3305   return space_list()->contains(ptr) ||
3306     (using_class_space() && class_space_list()->contains(ptr));

metaspace.hpp:

  270     return _allocated_capacity_words[Metaspace::NonClassType] +
  271       (Metaspace::using_class_space() ?
  272         _allocated_capacity_words[Metaspace::ClassType] : 0);

  285     return _allocated_used_words[Metaspace::NonClassType] +
  286       (Metaspace::using_class_space() ?
  287         _allocated_used_words[Metaspace::ClassType] : 0);

universe.cpp:

  849   assert((intptr_t)Universe::narrow_oop_base() <= 
(intptr_t)(Universe::heap()->base() -
  850     os::vm_page_size()) ||
  851            Universe::narrow_oop_base() == NULL, "invalid value");


Thanks,
Vladimir

On 8/2/13 1:31 PM, harold seigel wrote:
> Hi,
>
> Please review this updated webrev for bug 8003424:
> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>
> The updated webrev has a lot of changes from the previous webrev,
> including the following:
>
>     1. Class metaspace information is now output when
>     -XX:+PrintCompressedOopsMode is specified.
>
>     2. decode_klass_not_null(Register dst, Register src) no longer
>     clobbers R12.
>
>     3. Method using_class_vsm() was renamed to using_class_space().
>
>     4. Type narrowKlass was added and replaces narrowOop, where appropriate.
>
>     5. The Metaspace:: qualifier was removed, where it was unnecessary.
>
>     6. Metaspace::initialize_class_space() was made private.
>
>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was updated.
>
> Performance tests were run by Jenny using specjvm2008, specjbb2005, and
> specjbb2013.  The results showed no significant performance difference
> in terms of scores and gc behavior.
>
> Additional testing was done on Solaris Sparc and Linux x86 using
> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>
> Please let me know what additional tests should be run.
>
> Thanks!
> Harold
>
> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>> Hi Harold,
>>
>> > Usually the narrow_klass_base will be 32G and the
>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means that
>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12, unless
>> > we do multiple addq(r, narrow_klass_base_shifted()).  Does that make
>> sense?
>>
>> My bad, I miscalculated. But we have "perfect value" 0x800000000 and I
>> am tempted to use may be bts (bit set) to avoid R12 usage (assuming or
>> with check that class metaspace size < 32Gb).
>>
>> > Is there one prefix byte per instruction, or just for certain
>> instructions?
>>
>> "Not all instructions require a REX prefix in 64-bit mode. A prefix is
>> necessary only if an instruction references one of the extended
>> registers or uses a 64-bit operand."
>>
>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and =32
>> and big java heap. Recently we got several bugs which indicated that
>> we did not separate cleanly oops and klass pointers en/decoding.
>>
>> Thanks,
>> Vladimir
>>
>> On 7/24/13 11:35 AM, harold seigel wrote:
>>> Hi Vladimir,
>>>
>>> Thank you for the review!  Please see inline comments.
>>>
>>> Thanks, Harold
>>>
>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>> Nice clean up, Harold
>>>>>
>>>>> Could you add the size of class metaspace in output with
>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>>> remember an
>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>> Will be done in next webrev.
>>>>>
>>>>> Also it would be nice to print these info line (and compressed oops
>>>>> info
>>>>> line) in hs_err files.
>>> I filed an enhancement bug for this: 8021264
>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>
>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in x86_64.ad.
>>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also note
>>>>> that code in .ad file does not check the encoding mode for narrow
>>>>> klass/oop so it should be conservative and assume that arithmetic
>>>>> instructions are used.
>>> OK. Thanks.
>>>>>
>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>>>>> 4Gb so
>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>> encoding/decoding without destroying R12.
>>>>
>>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>>> bit is extended so you will get wrong result with address > 2gb).
>>> But the base will normally be 32Gb.  So this case won't happen very
>>> often.
>>>>
>>>> You definitely should not use R12 in decode_klass_not_null(Register
>>>> dst, Register src) method where you have free 'dst' register.
>>> Will be fixed in next webrev.
>>>>
>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>>> The idea was to avoid using R12 by using shifted base:
>>>>
>>>> decode:
>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>   }
>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>> }
>>>>
>>>> Universe::narrow_klass_base_shifted() is set only if
>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>>> (max positive int).
>>> Usually the narrow_klass_base will be 32G and the
>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means that
>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12, unless
>>> we do multiple addq(r, narrow_klass_base_shifted()).  Does that make
>>> sense?
>>>>
>>>> And you have general memory reservation problem. At least on Solaris,
>>>> as I remember, OS will always try to keep protected 4Kb pages between
>>>> different requested memory regions. That is why in jdk7 we first
>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>> protection page below heap to catch implicit NULL exceptions with
>>>> compressed oops.
>>>>
>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>> address or CompressedKlassPointersBase without CDS and with compressed
>>>> oops and with Xmx20Gb.
>>> I verifed that we get either cds_address+cds_total as the address, or
>>> CompressedKlassPointersBase as the address without CDS on Linux, Windows
>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap sizes and
>>> -Xmx32G.
>>>
>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the desired
>>> CDS address for class metaspace regardless of heap size.
>>>>
>>>>>
>>>>> instr_size_for_decode_klass_not_null() is ugly but unfortunately we
>>>>> can't do other way. I assume you use max size because depending on
>>>>> registers used in instructions you will or will not get prefix byte
>>>>> (r8-r15).
>>> Is there one prefix byte per instruction, or just for certain
>>> instructions?
>>>>>
>>>>> I will look on changes in more details may be late.
>>>>
>>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>>> which are not obvious.
>>> I changed using_class_vsm() to using_class_space().
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this fix for bug 8003424.
>>>>>>
>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>> Open bug links at:
>>>>>>
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>
>>>>>> JBS Bug links at
>>>>>>
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>
>>>>>>
>>>>>> This fix provides support for using compressed klass pointers with
>>>>>> CDS.
>>>>>> It also changes the class metaspace allocation on 64-bit platforms
>>>>>> when
>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the class
>>>>>> metaspace as part of the Java Heap allocation and locating it at the
>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>> separately,
>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>> metaspace
>>>>>> because it won't be backed up against the Java heap.  If CDS is being
>>>>>> used, then the CDS region will be allocated between the Java heap and
>>>>>> the metaspace.
>>>>>>
>>>>>> The new class metaspace allocation code tries to allocate memory at
>>>>>> 32G,
>>>>>> or above the CDS region, if it is present.  Because of this, encoding
>>>>>> and decoding of compressed klass pointers will always require use
>>>>>> of a
>>>>>> base register.  So, encoding and decoding of compressed klass
>>>>>> pointers
>>>>>> will differ from compressed oops.
>>>>>>
>>>>>> There are no class metaspace allocation changes if
>>>>>> UseCompressedKlassPointers is turned off or if running on a 32-bit
>>>>>> platform.
>>>>>>
>>>>>> The code changes also include some cleanup and will fix bugs 8016729,
>>>>>> 8011610, and 8003424.
>>>>>>
>>>>>>
>>>>>> Many of the modules in this webrev contain a lot of changes. Modules
>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were changed to
>>>>>> support the new encoding and decoding of compressed klass pointers.
>>>>>>
>>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>>> allocation for metaspace and the CDS region and to determine
>>>>>> compressed
>>>>>> klass pointer encoding base and shifting values.
>>>>>>
>>>>>> Most of the changes to module universe.cpp were to remove code
>>>>>> related
>>>>>> to allocating metaspace and remove code that considered compressed
>>>>>> klass
>>>>>> pointers when determining the compressed oops compression mechanism.
>>>>>>
>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as part of a
>>>>>> cleanup requested by Coleen.
>>>>>>
>>>>>>
>>>>>> These changes were tested with JCK Lang and VM tests, JTReg tests,
>>>>>> JPRT,
>>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>>> tests.  Most of the test were run with -Xshare:on and -Xshare:off
>>>>>> (with
>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>>> 64-Bit
>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS.  JCK tests were
>>>>>> run on Solaris x86.
>>>>>>
>>>>>> The performance impact of these changes is TBD.
>>>>>>
>>>>>> Thanks, Harold
>>>>>>
>>>>>>
>>>
>

From david.holmes at oracle.com  Mon Aug  5 21:15:12 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 06 Aug 2013 14:15:12 +1000
Subject: RFR (XXS) 8022093 - syntax error near "umpiconninfo_t" -- when
	building on Solaris 10
In-Reply-To: <51FFFF61.5070409@oracle.com>
References: <51FFDE6E.2090503@oracle.com> <51FFFF61.5070409@oracle.com>
Message-ID: <52007850.7020701@oracle.com>

Ioi the change looks fine - Reviewed.

On 6/08/2013 5:39 AM, serguei.spitsyn at oracle.com wrote:
> The fix is good.
> I guess, granting the DTrace permissions on a build machine would be
> another workaround.
> Probably, there is no big need to say it in the error message explicitly.

This has nothing to do with Dtrace permissions. The mpi.d file is broken 
and needs to be removed. You can either do that or rename it so dtrace 
ignores it.

Cheers,
David

> Thanks,
> Serguei
>
>
> On 8/5/13 10:18 AM, Ioi Lam wrote:
>> |Please review a very small fix:||
>> ||
>> ||http://cr.openjdk.java.net/~iklam/8022093/solaris_dtrace_002/||
>> ||
>> ||Bug: syntax error near "umpiconninfo_t" -- when building on Solaris 10||
>> ||
>> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022093||
>> ||https://jbs.oracle.com/bugs/browse/JDK-8022093||
>> ||
>> ||Summary of fix:||
>> ||
>> ||    OK -- it's not really fixing the build per-se, but I
>>     added more error messages to show users possible workarounds.
>>     Otherwise||it's fairly hard to figure out what to do.
>> ||
>> ||---vvv---||
>> ||Compiling dtrace.d||
>> ||dtrace: failed to compile script dtrace.d: "/usr/lib/dtrace/mpi.d",
>> line 68: syntax error near "umpiconninfo_t"||
>> ||*****************************************************************||
>> ||* If you are seeing 'syntax error near "umpiconninfo_t"' on Solaris||
>> ||* 10, try doing 'cd /usr/lib/dtrace && gzip mpi.d' as root, ||
>> ||* or set the environment variable HOTSPOT_DISABLE_DTRACE_PROBES||
>> ||* to disable dtrace probes for this build.||
>> ||*****************************************************************||
>> ||---^^^---||
>> ||
>> ||Tests:||
>> ||
>> ||    JPRT||
>> ||
>> ||Thanks||
>> ||- Ioi||
>> ||
>> |
>

From dmitry.samersoff at oracle.com  Tue Aug  6 06:20:51 2013
From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com)
Date: Tue, 06 Aug 2013 13:20:51 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8019396: SA-JDI OSThread class
	initialization throws an exception
Message-ID: <20130806132055.2ABAD48604@hg.openjdk.java.net>

Changeset: 22a5aff0df0b
Author:    dsamersoff
Date:      2013-08-06 14:28 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/22a5aff0df0b

8019396: SA-JDI OSThread class initialization throws an exception
Summary: Method sun.jvm.hotspot.runtime.OSThread.initialize throws a sun.jvm.hotspot.types.WrongTypeException
Reviewed-by: dholmes, mgerdin

! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java


From coleen.phillimore at oracle.com  Tue Aug  6 14:33:47 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 06 Aug 2013 17:33:47 -0400
Subject: RFR 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
Message-ID: <52016BBB.3040907@oracle.com>

Summary: ActiveMethodOopsCache was used to keep track of old versions of 
some methods that are cached in Universe but is buggy with permgen 
removal and not needed anymore

There was a crash in this function that I couldn't reproduce.  It was 
likely that the crash was for something else, but this is a lurking bug.

open webrev at http://cr.openjdk.java.net/~coleenp/8009728/
bug link at http://bugs.sun.com/view_bug.do?bug_id=8009728
local bug link https://jbs.oracle.com/bugs/browse/JDK-8009728

Tested with vm.quick.testlist which includes redefine classes tests and 
jck lang and vm tests.

Thanks,
Coleen

From yumin.qi at oracle.com  Tue Aug  6 15:38:01 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 06 Aug 2013 15:38:01 -0700
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
Message-ID: <52017AC9.9040809@oracle.com>

Please review:

http://cr.openjdk.java.net/~minqi/8019583/webrev0/ 
<http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>

Summary: The test will always pass since TestMT.java will always return 
value 0 to shell. Fix by recording failure value and exit with it.

Thanks
Yumin

From mikael.vidstedt at oracle.com  Tue Aug  6 16:36:12 2013
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 06 Aug 2013 16:36:12 -0700
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and Windows
	Server 2012 R2
Message-ID: <5201886C.1030206@oracle.com>


Please review the following change:

http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev

The patch adds support to os_windows.cpp for recognizing the upcoming 
Windows versions: Windows 8.1 and Windows Server 2012 R2.

The changed is based on the corresponding code on the JDK side[1][2][3].

Thanks,
Mikael

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
[2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
[3] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html


From christian.tornqvist at oracle.com  Tue Aug  6 16:52:26 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Tue, 6 Aug 2013 19:52:26 -0400
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows	Server 2012 R2
In-Reply-To: <5201886C.1030206@oracle.com>
References: <5201886C.1030206@oracle.com>
Message-ID: <006e01ce9300$014d2880$03e77980$@oracle.com>

Change looks good, thanks for fixing this :)

Thanks,
Christian

-----Original Message-----
From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Mikael Vidstedt
Sent: den 6 augusti 2013 19:36
To: hotspot-runtime-dev at openjdk.java.net
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2


Please review the following change:

http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev

The patch adds support to os_windows.cpp for recognizing the upcoming Windows versions: Windows 8.1 and Windows Server 2012 R2.

The changed is based on the corresponding code on the JDK side[1][2][3].

Thanks,
Mikael

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
[2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
[3]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html



From mikael.vidstedt at oracle.com  Tue Aug  6 17:01:51 2013
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 06 Aug 2013 17:01:51 -0700
Subject: code review (round 0) request for VS2010 IDE fix (8016601)
In-Reply-To: <51FC3457.30003@oracle.com>
References: <51FC3457.30003@oracle.com>
Message-ID: <52018E6F.1090803@oracle.com>


Dan,

I have not reviewed the actual changes, but FWIW I have verified that 
applying the patch does solve the linker error you mention. Thanks a lot 
for fixing!

Cheers,
Mikael

On 2013-08-02 15:36, Daniel D. Daugherty wrote:
> Greetings,
>
> I have have a proposed fix for the following bug:
>
>     8016601 Unable to build hsx24 on Windows using project creator and
>             Visual Studio
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016601
>     https://jbs.oracle.com/bugs/browse/JDK-8016601
>
> Here are the HSX-25 webrev URLs:
>
> OpenJDK: http://cr.openjdk.java.net/~dcubed/8016601-webrev/0-hsx25/
> Internal: http://javaweb.us.oracle.com/~ddaugher/8016601-webrev/0-hsx25/
>
> Testing:
> - JPRT windows_i586 and windows_x64 build and test
> - local windows_i586 cmd line builds for:
>   {OpenJDK, Oracle} x {Client, Server} VM x {product, debug, fastdebug}
> - local windows_i586 VS2010 builds for
>   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
> fastdebug}
> - local windows_x64 VS2010 builds for
>   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
> fastdebug}
>   Thanks to Ron for doing the windows_x64 testing
>
> Gory details are below. As always, comments, questions and
> suggestions are welome.
>
> Dan
>
>
> Gory Details:
>
> Build fixes:
> - VS2010 IDE builds are working again; fixes this failure mode:
>
> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\objectCountEventSender.obj 
> : warning LNK4042: object specified more than once; extras ignored
> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\errorReporter.obj 
> : warning LNK4042: object specified more than once; extras ignored
> 1>     Creating library 
> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.lib 
> and object 
> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.exp
> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
> "public: static void __cdecl 
> ObjectCountEventSender::disable_requestable_event(void)" 
> (?disable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced 
> in function "public: virtual void __thiscall 
> VM_GC_SendObjectCountEvent::doit(void)" 
> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
> "public: static void __cdecl 
> ObjectCountEventSender::enable_requestable_event(void)" 
> (?enable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced 
> in function "public: virtual void __thiscall 
> VM_GC_SendObjectCountEvent::doit(void)" 
> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.dll 
> : fatal error LNK1120: 2 unresolved externals
>
> - The ProjectCreator tool is modified to support two new options:
>   '-relativeAltSrcInclude' and '-altRelativeInclude'. Here's an
>   example use of the new options:
>
>       -relativeAltSrcInclude src\closed
>       -altRelativeInclude share\vm
>
>   which means config the project with some alternate source files in
>   src\closed\share\vm that will replace the corresponding files in
>   src\share\vm.
>
>   For example, src\closed\share\vm\utilities\errorReporter.cpp replaces
>   src\share\vm\utilities\errorReporter.cpp. In the VS2010 IDE, you'll
>   still be able to see src\share\vm\utilities\errorReporter.cpp in the
>   project source browser, but the icon will indicate that the file is
>   excluded from the project.
>
>   The ProjectCreator tool's file tree walking logic is modified to keep
>   track of each alternate source file that is found. If a corresponding
>   regular source file is found, then the regular source file is
>   excluded from the project in favor of the alternate source version.
>
> - VS2010 cmd line build no longer issue the following linker warnings:
>
>     link.exe @C:\Users\lfoltan\AppData\Local\Temp\nm9B65.tmp
>     errorReporter.obj : warning LNK4042: object specified more than 
> once; extras ignored
>     objectCountEventSender.obj : warning LNK4042: object specified 
> more than once; extras ignored
>
> Misc cleanups:
>
> - removed more "core" config support from various makefiles and scripts;
>   the "core" config is vestigal and was mostly removed years ago; the
>   "core" config is not the same as the "minimalvm" config.
> - removed extra references to ${ALTSRC}/share/vm/jfr objects
> - added some "AltSrc" versus "OpenJDK" identification to messages where
>   files are auto-generated
> - added some missing copyright headers
>


From tao.mao at oracle.com  Tue Aug  6 17:15:08 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Tue, 06 Aug 2013 17:15:08 -0700
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <5201886C.1030206@oracle.com>
References: <5201886C.1030206@oracle.com>
Message-ID: <5201918C.9060501@oracle.com>

Looks good. I bet you've tested the code on the two kinds of machines.

Thanks.
Tao

On 8/6/13 4:36 PM, Mikael Vidstedt wrote:
>
> Please review the following change:
>
> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>
> The patch adds support to os_windows.cpp for recognizing the upcoming 
> Windows versions: Windows 8.1 and Windows Server 2012 R2.
>
> The changed is based on the corresponding code on the JDK side[1][2][3].
>
> Thanks,
> Mikael
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
> [3] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>

From ron.durbin at oracle.com  Tue Aug  6 17:19:55 2013
From: ron.durbin at oracle.com (Ron Durbin)
Date: Tue, 6 Aug 2013 17:19:55 -0700 (PDT)
Subject: code review (round 0) request for VS2010 IDE fix (8016601)
In-Reply-To: <51FC3457.30003@oracle.com>
References: <51FC3457.30003@oracle.com>
Message-ID: <b2e6ed5e-067d-4696-ad24-1c18f5e63cae@default>

Your code looks good and it resolves the reported defect.


> -----Original Message-----
> From: Daniel D. Daugherty
> Sent: Friday, August 02, 2013 4:36 PM
> To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; build-dev
> Subject: code review (round 0) request for VS2010 IDE fix (8016601)
> 
> Greetings,
> 
> I have have a proposed fix for the following bug:
> 
>      8016601 Unable to build hsx24 on Windows using project creator and
>              Visual Studio
>      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016601
>      https://jbs.oracle.com/bugs/browse/JDK-8016601
> 
> Here are the HSX-25 webrev URLs:
> 
> OpenJDK: http://cr.openjdk.java.net/~dcubed/8016601-webrev/0-hsx25/
> Internal: http://javaweb.us.oracle.com/~ddaugher/8016601-webrev/0-hsx25/
> 
> Testing:
> - JPRT windows_i586 and windows_x64 build and test
> - local windows_i586 cmd line builds for:
>    {OpenJDK, Oracle} x {Client, Server} VM x {product, debug, fastdebug}
> - local windows_i586 VS2010 builds for
>    {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, fastdebug}
> - local windows_x64 VS2010 builds for
>    {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, fastdebug}
>    Thanks to Ron for doing the windows_x64 testing
> 
> Gory details are below. As always, comments, questions and suggestions are welome.
> 
> Dan
> 
> 
> Gory Details:
> 
> Build fixes:
> - VS2010 IDE builds are working again; fixes this failure mode:
> 
> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\obj
> 1>ectCountEventSender.obj
> : warning LNK4042: object specified more than once; extras ignored
> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\err
> 1>orReporter.obj
> : warning LNK4042: object specified more than once; extras ignored
> 1>     Creating library
> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.lib
> and object
> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.exp
> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol
> "public: static void __cdecl
> ObjectCountEventSender::disable_requestable_event(void)"
> (?disable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced in function "public:
> virtual void __thiscall VM_GC_SendObjectCountEvent::doit(void)"
> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol
> "public: static void __cdecl
> ObjectCountEventSender::enable_requestable_event(void)"
> (?enable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced in function "public:
> virtual void __thiscall VM_GC_SendObjectCountEvent::doit(void)"
> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm
> 1>.dll
> : fatal error LNK1120: 2 unresolved externals
> 
> - The ProjectCreator tool is modified to support two new options:
>    '-relativeAltSrcInclude' and '-altRelativeInclude'. Here's an
>    example use of the new options:
> 
>        -relativeAltSrcInclude src\closed
>        -altRelativeInclude share\vm
> 
>    which means config the project with some alternate source files in
>    src\closed\share\vm that will replace the corresponding files in
>    src\share\vm.
> 
>    For example, src\closed\share\vm\utilities\errorReporter.cpp replaces
>    src\share\vm\utilities\errorReporter.cpp. In the VS2010 IDE, you'll
>    still be able to see src\share\vm\utilities\errorReporter.cpp in the
>    project source browser, but the icon will indicate that the file is
>    excluded from the project.
> 
>    The ProjectCreator tool's file tree walking logic is modified to keep
>    track of each alternate source file that is found. If a corresponding
>    regular source file is found, then the regular source file is
>    excluded from the project in favor of the alternate source version.
> 
> - VS2010 cmd line build no longer issue the following linker warnings:
> 
>      link.exe @C:\Users\lfoltan\AppData\Local\Temp\nm9B65.tmp
>      errorReporter.obj : warning LNK4042: object specified more than once; extras ignored
>      objectCountEventSender.obj : warning LNK4042: object specified more than once; extras
> ignored
> 
> Misc cleanups:
> 
> - removed more "core" config support from various makefiles and scripts;
>    the "core" config is vestigal and was mostly removed years ago; the
>    "core" config is not the same as the "minimalvm" config.
> - removed extra references to ${ALTSRC}/share/vm/jfr objects
> - added some "AltSrc" versus "OpenJDK" identification to messages where
>    files are auto-generated
> - added some missing copyright headers
> 

From daniel.daugherty at oracle.com  Tue Aug  6 18:48:09 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 06 Aug 2013 19:48:09 -0600
Subject: code review (round 0) request for VS2010 IDE fix (8016601)
In-Reply-To: <52018E6F.1090803@oracle.com>
References: <51FC3457.30003@oracle.com> <52018E6F.1090803@oracle.com>
Message-ID: <5201A759.6010303@oracle.com>

Thanks for being another tester for these changes!

Just curious: which OS and VS version?

Dan


On 8/6/13 6:01 PM, Mikael Vidstedt wrote:
>
> Dan,
>
> I have not reviewed the actual changes, but FWIW I have verified that 
> applying the patch does solve the linker error you mention. Thanks a 
> lot for fixing!
>
> Cheers,
> Mikael
>
> On 2013-08-02 15:36, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I have have a proposed fix for the following bug:
>>
>>     8016601 Unable to build hsx24 on Windows using project creator and
>>             Visual Studio
>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016601
>>     https://jbs.oracle.com/bugs/browse/JDK-8016601
>>
>> Here are the HSX-25 webrev URLs:
>>
>> OpenJDK: http://cr.openjdk.java.net/~dcubed/8016601-webrev/0-hsx25/
>> Internal: http://javaweb.us.oracle.com/~ddaugher/8016601-webrev/0-hsx25/
>>
>> Testing:
>> - JPRT windows_i586 and windows_x64 build and test
>> - local windows_i586 cmd line builds for:
>>   {OpenJDK, Oracle} x {Client, Server} VM x {product, debug, fastdebug}
>> - local windows_i586 VS2010 builds for
>>   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
>> fastdebug}
>> - local windows_x64 VS2010 builds for
>>   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
>> fastdebug}
>>   Thanks to Ron for doing the windows_x64 testing
>>
>> Gory details are below. As always, comments, questions and
>> suggestions are welome.
>>
>> Dan
>>
>>
>> Gory Details:
>>
>> Build fixes:
>> - VS2010 IDE builds are working again; fixes this failure mode:
>>
>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\objectCountEventSender.obj 
>> : warning LNK4042: object specified more than once; extras ignored
>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\errorReporter.obj 
>> : warning LNK4042: object specified more than once; extras ignored
>> 1>     Creating library 
>> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.lib 
>> and object 
>> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.exp
>> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
>> "public: static void __cdecl 
>> ObjectCountEventSender::disable_requestable_event(void)" 
>> (?disable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced 
>> in function "public: virtual void __thiscall 
>> VM_GC_SendObjectCountEvent::doit(void)" 
>> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
>> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
>> "public: static void __cdecl 
>> ObjectCountEventSender::enable_requestable_event(void)" 
>> (?enable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced 
>> in function "public: virtual void __thiscall 
>> VM_GC_SendObjectCountEvent::doit(void)" 
>> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.dll 
>> : fatal error LNK1120: 2 unresolved externals
>>
>> - The ProjectCreator tool is modified to support two new options:
>>   '-relativeAltSrcInclude' and '-altRelativeInclude'. Here's an
>>   example use of the new options:
>>
>>       -relativeAltSrcInclude src\closed
>>       -altRelativeInclude share\vm
>>
>>   which means config the project with some alternate source files in
>>   src\closed\share\vm that will replace the corresponding files in
>>   src\share\vm.
>>
>>   For example, src\closed\share\vm\utilities\errorReporter.cpp replaces
>>   src\share\vm\utilities\errorReporter.cpp. In the VS2010 IDE, you'll
>>   still be able to see src\share\vm\utilities\errorReporter.cpp in the
>>   project source browser, but the icon will indicate that the file is
>>   excluded from the project.
>>
>>   The ProjectCreator tool's file tree walking logic is modified to keep
>>   track of each alternate source file that is found. If a corresponding
>>   regular source file is found, then the regular source file is
>>   excluded from the project in favor of the alternate source version.
>>
>> - VS2010 cmd line build no longer issue the following linker warnings:
>>
>>     link.exe @C:\Users\lfoltan\AppData\Local\Temp\nm9B65.tmp
>>     errorReporter.obj : warning LNK4042: object specified more than 
>> once; extras ignored
>>     objectCountEventSender.obj : warning LNK4042: object specified 
>> more than once; extras ignored
>>
>> Misc cleanups:
>>
>> - removed more "core" config support from various makefiles and scripts;
>>   the "core" config is vestigal and was mostly removed years ago; the
>>   "core" config is not the same as the "minimalvm" config.
>> - removed extra references to ${ALTSRC}/share/vm/jfr objects
>> - added some "AltSrc" versus "OpenJDK" identification to messages where
>>   files are auto-generated
>> - added some missing copyright headers
>>
>


From daniel.daugherty at oracle.com  Tue Aug  6 18:48:31 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 06 Aug 2013 19:48:31 -0600
Subject: code review (round 0) request for VS2010 IDE fix (8016601)
In-Reply-To: <b2e6ed5e-067d-4696-ad24-1c18f5e63cae@default>
References: <51FC3457.30003@oracle.com>
	<b2e6ed5e-067d-4696-ad24-1c18f5e63cae@default>
Message-ID: <5201A76F.9010609@oracle.com>

Ron,

Thanks for the review!

Dan


On 8/6/13 6:19 PM, Ron Durbin wrote:
> Your code looks good and it resolves the reported defect.
>
>
>> -----Original Message-----
>> From: Daniel D. Daugherty
>> Sent: Friday, August 02, 2013 4:36 PM
>> To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; build-dev
>> Subject: code review (round 0) request for VS2010 IDE fix (8016601)
>>
>> Greetings,
>>
>> I have have a proposed fix for the following bug:
>>
>>       8016601 Unable to build hsx24 on Windows using project creator and
>>               Visual Studio
>>       http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016601
>>       https://jbs.oracle.com/bugs/browse/JDK-8016601
>>
>> Here are the HSX-25 webrev URLs:
>>
>> OpenJDK: http://cr.openjdk.java.net/~dcubed/8016601-webrev/0-hsx25/
>> Internal: http://javaweb.us.oracle.com/~ddaugher/8016601-webrev/0-hsx25/
>>
>> Testing:
>> - JPRT windows_i586 and windows_x64 build and test
>> - local windows_i586 cmd line builds for:
>>     {OpenJDK, Oracle} x {Client, Server} VM x {product, debug, fastdebug}
>> - local windows_i586 VS2010 builds for
>>     {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, fastdebug}
>> - local windows_x64 VS2010 builds for
>>     {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, fastdebug}
>>     Thanks to Ron for doing the windows_x64 testing
>>
>> Gory details are below. As always, comments, questions and suggestions are welome.
>>
>> Dan
>>
>>
>> Gory Details:
>>
>> Build fixes:
>> - VS2010 IDE builds are working again; fixes this failure mode:
>>
>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\obj
>> 1>ectCountEventSender.obj
>> : warning LNK4042: object specified more than once; extras ignored
>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\err
>> 1>orReporter.obj
>> : warning LNK4042: object specified more than once; extras ignored
>> 1>     Creating library
>> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.lib
>> and object
>> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.exp
>> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol
>> "public: static void __cdecl
>> ObjectCountEventSender::disable_requestable_event(void)"
>> (?disable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced in function "public:
>> virtual void __thiscall VM_GC_SendObjectCountEvent::doit(void)"
>> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
>> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol
>> "public: static void __cdecl
>> ObjectCountEventSender::enable_requestable_event(void)"
>> (?enable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced in function "public:
>> virtual void __thiscall VM_GC_SendObjectCountEvent::doit(void)"
>> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm
>> 1>.dll
>> : fatal error LNK1120: 2 unresolved externals
>>
>> - The ProjectCreator tool is modified to support two new options:
>>     '-relativeAltSrcInclude' and '-altRelativeInclude'. Here's an
>>     example use of the new options:
>>
>>         -relativeAltSrcInclude src\closed
>>         -altRelativeInclude share\vm
>>
>>     which means config the project with some alternate source files in
>>     src\closed\share\vm that will replace the corresponding files in
>>     src\share\vm.
>>
>>     For example, src\closed\share\vm\utilities\errorReporter.cpp replaces
>>     src\share\vm\utilities\errorReporter.cpp. In the VS2010 IDE, you'll
>>     still be able to see src\share\vm\utilities\errorReporter.cpp in the
>>     project source browser, but the icon will indicate that the file is
>>     excluded from the project.
>>
>>     The ProjectCreator tool's file tree walking logic is modified to keep
>>     track of each alternate source file that is found. If a corresponding
>>     regular source file is found, then the regular source file is
>>     excluded from the project in favor of the alternate source version.
>>
>> - VS2010 cmd line build no longer issue the following linker warnings:
>>
>>       link.exe @C:\Users\lfoltan\AppData\Local\Temp\nm9B65.tmp
>>       errorReporter.obj : warning LNK4042: object specified more than once; extras ignored
>>       objectCountEventSender.obj : warning LNK4042: object specified more than once; extras
>> ignored
>>
>> Misc cleanups:
>>
>> - removed more "core" config support from various makefiles and scripts;
>>     the "core" config is vestigal and was mostly removed years ago; the
>>     "core" config is not the same as the "minimalvm" config.
>> - removed extra references to ${ALTSRC}/share/vm/jfr objects
>> - added some "AltSrc" versus "OpenJDK" identification to messages where
>>     files are auto-generated
>> - added some missing copyright headers
>>


From serguei.spitsyn at oracle.com  Tue Aug  6 20:55:49 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 07 Aug 2013 03:55:49 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 7187554: JSR 292: JVMTI PopFrame needs to
	handle appendix arguments
Message-ID: <20130807035553.7DAED48654@hg.openjdk.java.net>

Changeset: ca0165daa6ec
Author:    sspitsyn
Date:      2013-08-06 16:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ca0165daa6ec

7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments
Summary: Restore the appendix argument after PopFrame() call
Reviewed-by: twisti, coleenp
Contributed-by: serguei.spitsyn at oracle.com

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp


From david.holmes at oracle.com  Wed Aug  7 01:31:17 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Wed, 07 Aug 2013 08:31:17 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 8012144: multiple SIGSEGVs fails on staxf
Message-ID: <20130807083122.0B83548663@hg.openjdk.java.net>

Changeset: cd25d3be91c5
Author:    vladidan
Date:      2013-08-06 20:01 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cd25d3be91c5

8012144: multiple SIGSEGVs fails on staxf
Summary: Forward port of 7u change to add additional fence() on RMO platforms, with a load_acquire on all platforms
Reviewed-by: dholmes, kvn

! src/share/vm/utilities/taskqueue.hpp


From david.holmes at oracle.com  Wed Aug  7 02:25:19 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Wed, 07 Aug 2013 09:25:19 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130807092620.6D2A748664@hg.openjdk.java.net>

Changeset: c54a3122f9c8
Author:    omajid
Date:      2013-08-06 12:28 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c54a3122f9c8

8022188: Make zero compile after 8016131 and 8016697
Reviewed-by: dholmes, twisti

! src/cpu/zero/vm/entryFrame_zero.hpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/stubGenerator_zero.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp

Changeset: 196aa14f9f29
Author:    dholmes
Date:      2013-08-06 21:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/196aa14f9f29

Merge



From harold.seigel at oracle.com  Wed Aug  7 05:02:56 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 07 Aug 2013 08:02:56 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <51FFFB29.9070304@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
	<51FFFB29.9070304@oracle.com>
Message-ID: <52023770.9070804@oracle.com>

Hi Coleen,

Thanks for all the comments.  Please see my replies inline.

Harold

On 8/5/2013 3:21 PM, Coleen Phillimore wrote:
>
> On 08/02/2013 04:31 PM, harold seigel wrote:
>> Hi,
>>
>> Please review this updated webrev for bug 8003424: 
>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/ 
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>
>> The updated webrev has a lot of changes from the previous webrev, 
>> including the following:
>>
>>     1. Class metaspace information is now output when
>>     -XX:+PrintCompressedOopsMode is specified.
>>
>>     2. decode_klass_not_null(Register dst, Register src) no longer
>>     clobbers R12.
>>
>
> If decode_klass_not_null(src, dest) doesn't use r12, isn't the size 
> calculated by *instr_size_for_decode_klass_not_null* now wrong?   Or 
> is this size calculation only valid for the case where you only have 
> one register?  Or can this size be a max size?
This size is a max size.
>
> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/src/share/vm/memory/heap.cpp.frames.html
>
> In this file can you spell out segm_r_aligned to something more 
> descriptive - like reserved_segment_alignment, reserved_segments_size, 
> committed_segments_size.
This change will be in the next webrev.
>
> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/src/share/vm/memory/metaspace.cpp.udiff.html
>
> *+   if (PrintCompressedOopsMode || (PrintMiscellaneous && Verbose)) {*
> *+     gclog_or_tty->print_cr("Narrow klass base: " PTR_FORMAT ", Narrow klass shift: " SIZE_FORMAT,*
>
> I see this conditional comes from universe.cpp but I don't see why 
> this should be printed for the OR condition: PrintMiscellaneous && 
> Verbose.
I removed the second OR condition.
>
> 2941 #ifdef _LP64
> 2942     Universe::set_narrow_klass_base((address)_space_list->current_virtual_space()->bottom()
>
> Put a comment why you do this.  It's so UseCompressedKlassPointers 
> decoding "works" while you are creating the shared archive.  The oops 
> are thrown away right now so it doesn't matter that the encoded value 
> uses a different base during dumping than it will use during 
> UseSharedSpaces.   When we share String oops, we'll have to fix this 
> code but I don't know how to fix this yet. Maybe add code that always 
> requires that the CDS archive base is the lower of the two bases.   
> Not a problem with your code.
>
> Maybe you should assert that UseCompressedOops and KlassPtrs are set 
> here though.
I added both a comment and an assert.
>
> 3012   if (using_class_space()) {
> 3013     _class_space_list = new VirtualSpaceList(rs);
> 3014   }
>
> This function initialize_class_space() is always called when you are 
> using_class_space() so why this conditional?  Shouldn't this also be 
> moved to 2917 under where it's called (or above) in the ifdef LP64 
> since it's LP64 only now?
I changed the conditional to an assert.
>
> 2557   if ((mdtype == Metaspace::ClassType) && !Metaspace::using_class_space()) {
> 2558     return 0;
> 2559   }
> One way to shorten this expression that appears a few times, is to add 
> an inlined overloaded using_class_space(MetadataType).
I'd prefer to leave this code as is.  This expression occurs only twice 
and I think the existing code is more descriptive than a new function 
would be.
>
> This looks really good.  I've been through it a few times and I don't 
> see any problems, other than these suggestions here.
>
> Thanks!
> Coleen
>
>>
>>     3. Method using_class_vsm() was renamed to using_class_space().
>>
>>     4. Type narrowKlass was added and replaces narrowOop, where
>>     appropriate.
>>
>>     5. The Metaspace:: qualifier was removed, where it was unnecessary.
>>
>>     6. Metaspace::initialize_class_space() was made private.
>>
>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>>     updated.
>>
>> Performance tests were run by Jenny using specjvm2008, specjbb2005, 
>> and specjbb2013.  The results showed no significant performance 
>> difference in terms of scores and gc behavior.
>>
>> Additional testing was done on Solaris Sparc and Linux x86 using 
>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>
>> Please let me know what additional tests should be run.
>>
>> Thanks!
>> Harold
>>
>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>> Hi Harold,
>>>
>>> > Usually the narrow_klass_base will be 32G and the
>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means 
>>> that
>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12, 
>>> unless
>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>> make sense?
>>>
>>> My bad, I miscalculated. But we have "perfect value" 0x800000000 and 
>>> I am tempted to use may be bts (bit set) to avoid R12 usage 
>>> (assuming or with check that class metaspace size < 32Gb).
>>>
>>> > Is there one prefix byte per instruction, or just for certain 
>>> instructions?
>>>
>>> "Not all instructions require a REX prefix in 64-bit mode. A prefix 
>>> is necessary only if an instruction references one of the extended 
>>> registers or uses a 64-bit operand."
>>>
>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and =32 
>>> and big java heap. Recently we got several bugs which indicated that 
>>> we did not separate cleanly oops and klass pointers en/decoding.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>> Hi Vladimir,
>>>>
>>>> Thank you for the review!  Please see inline comments.
>>>>
>>>> Thanks, Harold
>>>>
>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>> Nice clean up, Harold
>>>>>>
>>>>>> Could you add the size of class metaspace in output with
>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to 
>>>>>> remember an
>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>> Will be done in next webrev.
>>>>>>
>>>>>> Also it would be nice to print these info line (and compressed 
>>>>>> oops info
>>>>>> line) in hs_err files.
>>>> I filed an enhancement bug for this: 8021264
>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>
>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in 
>>>>>> x86_64.ad.
>>>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also note
>>>>>> that code in .ad file does not check the encoding mode for narrow
>>>>>> klass/oop so it should be conservative and assume that arithmetic
>>>>>> instructions are used.
>>>> OK. Thanks.
>>>>>>
>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below 
>>>>>> 4Gb so
>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>> encoding/decoding without destroying R12.
>>>>>
>>>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>> But the base will normally be 32Gb.  So this case won't happen very 
>>>> often.
>>>>>
>>>>> You definitely should not use R12 in decode_klass_not_null(Register
>>>>> dst, Register src) method where you have free 'dst' register.
>>>> Will be fixed in next webrev.
>>>>>
>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>
>>>>> decode:
>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>   }
>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>> }
>>>>>
>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>>>> (max positive int).
>>>> Usually the narrow_klass_base will be 32G and the
>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means 
>>>> that
>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12, 
>>>> unless
>>>> we do multiple addq(r, narrow_klass_base_shifted()).  Does that 
>>>> make sense?
>>>>>
>>>>> And you have general memory reservation problem. At least on Solaris,
>>>>> as I remember, OS will always try to keep protected 4Kb pages between
>>>>> different requested memory regions. That is why in jdk7 we first
>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>> compressed oops.
>>>>>
>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>> address or CompressedKlassPointersBase without CDS and with 
>>>>> compressed
>>>>> oops and with Xmx20Gb.
>>>> I verifed that we get either cds_address+cds_total as the address, or
>>>> CompressedKlassPointersBase as the address without CDS on Linux, 
>>>> Windows
>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap sizes and
>>>> -Xmx32G.
>>>>
>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the 
>>>> desired
>>>> CDS address for class metaspace regardless of heap size.
>>>>>
>>>>>>
>>>>>> instr_size_for_decode_klass_not_null() is ugly but unfortunately we
>>>>>> can't do other way. I assume you use max size because depending on
>>>>>> registers used in instructions you will or will not get prefix byte
>>>>>> (r8-r15).
>>>> Is there one prefix byte per instruction, or just for certain 
>>>> instructions?
>>>>>>
>>>>>> I will look on changes in more details may be late.
>>>>>
>>>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>>>> which are not obvious.
>>>> I changed using_class_vsm() to using_class_space().
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review this fix for bug 8003424.
>>>>>>>
>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>> Open bug links at:
>>>>>>>
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>
>>>>>>> JBS Bug links at
>>>>>>>
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>
>>>>>>>
>>>>>>> This fix provides support for using compressed klass pointers 
>>>>>>> with CDS.
>>>>>>> It also changes the class metaspace allocation on 64-bit 
>>>>>>> platforms when
>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the 
>>>>>>> class
>>>>>>> metaspace as part of the Java Heap allocation and locating it at 
>>>>>>> the
>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>> separately,
>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>> metaspace
>>>>>>> because it won't be backed up against the Java heap. If CDS is 
>>>>>>> being
>>>>>>> used, then the CDS region will be allocated between the Java 
>>>>>>> heap and
>>>>>>> the metaspace.
>>>>>>>
>>>>>>> The new class metaspace allocation code tries to allocate memory at
>>>>>>> 32G,
>>>>>>> or above the CDS region, if it is present.  Because of this, 
>>>>>>> encoding
>>>>>>> and decoding of compressed klass pointers will always require 
>>>>>>> use of a
>>>>>>> base register.  So, encoding and decoding of compressed klass 
>>>>>>> pointers
>>>>>>> will differ from compressed oops.
>>>>>>>
>>>>>>> There are no class metaspace allocation changes if
>>>>>>> UseCompressedKlassPointers is turned off or if running on a 32-bit
>>>>>>> platform.
>>>>>>>
>>>>>>> The code changes also include some cleanup and will fix bugs 
>>>>>>> 8016729,
>>>>>>> 8011610, and 8003424.
>>>>>>>
>>>>>>>
>>>>>>> Many of the modules in this webrev contain a lot of changes. 
>>>>>>> Modules
>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were changed to
>>>>>>> support the new encoding and decoding of compressed klass pointers.
>>>>>>>
>>>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>>>> allocation for metaspace and the CDS region and to determine 
>>>>>>> compressed
>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>
>>>>>>> Most of the changes to module universe.cpp were to remove code 
>>>>>>> related
>>>>>>> to allocating metaspace and remove code that considered compressed
>>>>>>> klass
>>>>>>> pointers when determining the compressed oops compression 
>>>>>>> mechanism.
>>>>>>>
>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as part 
>>>>>>> of a
>>>>>>> cleanup requested by Coleen.
>>>>>>>
>>>>>>>
>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg tests,
>>>>>>> JPRT,
>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>>>> tests.  Most of the test were run with -Xshare:on and 
>>>>>>> -Xshare:off (with
>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>>>> 64-Bit
>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests 
>>>>>>> were
>>>>>>> run on Solaris x86.
>>>>>>>
>>>>>>> The performance impact of these changes is TBD.
>>>>>>>
>>>>>>> Thanks, Harold
>>>>>>>
>>>>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130807/0616ea3c/attachment-0001.html 

From david.holmes at oracle.com  Wed Aug  7 05:33:13 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 07 Aug 2013 22:33:13 +1000
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
In-Reply-To: <52017AC9.9040809@oracle.com>
References: <52017AC9.9040809@oracle.com>
Message-ID: <52023E89.3060706@oracle.com>

Hi Yumin,

As I understand the bug report the issue is more with the shell script 
returning the value of $? which no longer refers to the execution of the 
test but the evaluation of the if [ $? == 0 ]

David

On 7/08/2013 8:38 AM, Yumin Qi wrote:
> Please review:
>
> http://cr.openjdk.java.net/~minqi/8019583/webrev0/
> <http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>
>
> Summary: The test will always pass since TestMT.java will always return
> value 0 to shell. Fix by recording failure value and exit with it.
>
> Thanks
> Yumin

From coleen.phillimore at oracle.com  Wed Aug  7 05:33:26 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 07 Aug 2013 08:33:26 -0400
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
In-Reply-To: <52017AC9.9040809@oracle.com>
References: <52017AC9.9040809@oracle.com>
Message-ID: <52023E96.4000904@oracle.com>


Yumin,
Looks good.
Coleen

On 8/6/2013 6:38 PM, Yumin Qi wrote:
> Please review:
>
> http://cr.openjdk.java.net/~minqi/8019583/webrev0/ 
> <http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>
>
> Summary: The test will always pass since TestMT.java will always 
> return value 0 to shell. Fix by recording failure value and exit with it.
>
> Thanks
> Yumin


From ron.durbin at oracle.com  Wed Aug  7 06:33:35 2013
From: ron.durbin at oracle.com (Ron Durbin)
Date: Wed, 7 Aug 2013 06:33:35 -0700 (PDT)
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <5201886C.1030206@oracle.com>
References: <5201886C.1030206@oracle.com>
Message-ID: <6964c1ae-f549-4356-a59e-a914fff9f30b@default>

Not a cap R review, but I have reviewed your changes and they look good.

Ron

> -----Original Message-----
> From: Mikael Vidstedt
> Sent: Tuesday, August 06, 2013 5:36 PM
> To: hotspot-runtime-dev at openjdk.java.net
> Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012
> R2
> 
> 
> Please review the following change:
> 
> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
> 
> The patch adds support to os_windows.cpp for recognizing the upcoming Windows versions:
> Windows 8.1 and Windows Server 2012 R2.
> 
> The changed is based on the corresponding code on the JDK side[1][2][3].
> 
> Thanks,
> Mikael
> 
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
> [3]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
> 

From coleen.phillimore at oracle.com  Wed Aug  7 06:39:38 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 07 Aug 2013 09:39:38 -0400
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <5201886C.1030206@oracle.com>
References: <5201886C.1030206@oracle.com>
Message-ID: <52024E1A.4000908@oracle.com>


It looks like the code under the case for all these releases, should be 
different case statements for each, rather than these cascading 'if' 
statements.  And make 1668-1673 a new function returning si.   So if we 
have a new release, in general it will work because the default will 
print out something.   But a better default would be lines 1712-1717 
which are dead code now.

Sorry, I know it's simple and urgent but this seems to be getting 
increasingly ugly.

Thanks,
Coleen

On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>
> Please review the following change:
>
> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>
> The patch adds support to os_windows.cpp for recognizing the upcoming 
> Windows versions: Windows 8.1 and Windows Server 2012 R2.
>
> The changed is based on the corresponding code on the JDK side[1][2][3].
>
> Thanks,
> Mikael
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
> [3] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>


From coleen.phillimore at oracle.com  Wed Aug  7 06:46:09 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 07 Aug 2013 09:46:09 -0400
Subject: code review (round 0) request for VS2010 IDE fix (8016601)
In-Reply-To: <52018E6F.1090803@oracle.com>
References: <51FC3457.30003@oracle.com> <52018E6F.1090803@oracle.com>
Message-ID: <52024FA1.9090005@oracle.com>


Dan, this looks good.  Thank you for fixing it and removing the old core 
build, which is likely broken.

Thanks,
Coleen

On 8/6/2013 8:01 PM, Mikael Vidstedt wrote:
>
> Dan,
>
> I have not reviewed the actual changes, but FWIW I have verified that 
> applying the patch does solve the linker error you mention. Thanks a 
> lot for fixing!
>
> Cheers,
> Mikael
>
> On 2013-08-02 15:36, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I have have a proposed fix for the following bug:
>>
>>     8016601 Unable to build hsx24 on Windows using project creator and
>>             Visual Studio
>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016601
>>     https://jbs.oracle.com/bugs/browse/JDK-8016601
>>
>> Here are the HSX-25 webrev URLs:
>>
>> OpenJDK: http://cr.openjdk.java.net/~dcubed/8016601-webrev/0-hsx25/
>> Internal: http://javaweb.us.oracle.com/~ddaugher/8016601-webrev/0-hsx25/
>>
>> Testing:
>> - JPRT windows_i586 and windows_x64 build and test
>> - local windows_i586 cmd line builds for:
>>   {OpenJDK, Oracle} x {Client, Server} VM x {product, debug, fastdebug}
>> - local windows_i586 VS2010 builds for
>>   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
>> fastdebug}
>> - local windows_x64 VS2010 builds for
>>   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
>> fastdebug}
>>   Thanks to Ron for doing the windows_x64 testing
>>
>> Gory details are below. As always, comments, questions and
>> suggestions are welome.
>>
>> Dan
>>
>>
>> Gory Details:
>>
>> Build fixes:
>> - VS2010 IDE builds are working again; fixes this failure mode:
>>
>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\objectCountEventSender.obj 
>> : warning LNK4042: object specified more than once; extras ignored
>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\errorReporter.obj 
>> : warning LNK4042: object specified more than once; extras ignored
>> 1>     Creating library 
>> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.lib 
>> and object 
>> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.exp
>> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
>> "public: static void __cdecl 
>> ObjectCountEventSender::disable_requestable_event(void)" 
>> (?disable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced 
>> in function "public: virtual void __thiscall 
>> VM_GC_SendObjectCountEvent::doit(void)" 
>> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
>> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
>> "public: static void __cdecl 
>> ObjectCountEventSender::enable_requestable_event(void)" 
>> (?enable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced 
>> in function "public: virtual void __thiscall 
>> VM_GC_SendObjectCountEvent::doit(void)" 
>> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.dll 
>> : fatal error LNK1120: 2 unresolved externals
>>
>> - The ProjectCreator tool is modified to support two new options:
>>   '-relativeAltSrcInclude' and '-altRelativeInclude'. Here's an
>>   example use of the new options:
>>
>>       -relativeAltSrcInclude src\closed
>>       -altRelativeInclude share\vm
>>
>>   which means config the project with some alternate source files in
>>   src\closed\share\vm that will replace the corresponding files in
>>   src\share\vm.
>>
>>   For example, src\closed\share\vm\utilities\errorReporter.cpp replaces
>>   src\share\vm\utilities\errorReporter.cpp. In the VS2010 IDE, you'll
>>   still be able to see src\share\vm\utilities\errorReporter.cpp in the
>>   project source browser, but the icon will indicate that the file is
>>   excluded from the project.
>>
>>   The ProjectCreator tool's file tree walking logic is modified to keep
>>   track of each alternate source file that is found. If a corresponding
>>   regular source file is found, then the regular source file is
>>   excluded from the project in favor of the alternate source version.
>>
>> - VS2010 cmd line build no longer issue the following linker warnings:
>>
>>     link.exe @C:\Users\lfoltan\AppData\Local\Temp\nm9B65.tmp
>>     errorReporter.obj : warning LNK4042: object specified more than 
>> once; extras ignored
>>     objectCountEventSender.obj : warning LNK4042: object specified 
>> more than once; extras ignored
>>
>> Misc cleanups:
>>
>> - removed more "core" config support from various makefiles and scripts;
>>   the "core" config is vestigal and was mostly removed years ago; the
>>   "core" config is not the same as the "minimalvm" config.
>> - removed extra references to ${ALTSRC}/share/vm/jfr objects
>> - added some "AltSrc" versus "OpenJDK" identification to messages where
>>   files are auto-generated
>> - added some missing copyright headers
>>
>


From daniel.daugherty at oracle.com  Wed Aug  7 07:10:40 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 07 Aug 2013 08:10:40 -0600
Subject: code review (round 0) request for VS2010 IDE fix (8016601)
In-Reply-To: <52024FA1.9090005@oracle.com>
References: <51FC3457.30003@oracle.com> <52018E6F.1090803@oracle.com>
	<52024FA1.9090005@oracle.com>
Message-ID: <52025560.7050603@oracle.com>

Adding back serviceability-dev at openjdk.java.net and 
build-dev at openjdk.java.net

Reminder: "reply to list" only replies to _one_ list.

On 8/7/13 7:46 AM, Coleen Phillimore wrote:
>
> Dan, this looks good.  Thank you for fixing it

Thanks for the review!


> and removing the old core build, which is likely broken.

Yes, when I ran the IDE batch build of all the configs, the core
configs failed quite nicely.

Dan


>
> Thanks,
> Coleen
>
> On 8/6/2013 8:01 PM, Mikael Vidstedt wrote:
>>
>> Dan,
>>
>> I have not reviewed the actual changes, but FWIW I have verified that 
>> applying the patch does solve the linker error you mention. Thanks a 
>> lot for fixing!
>>
>> Cheers,
>> Mikael
>>
>> On 2013-08-02 15:36, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I have have a proposed fix for the following bug:
>>>
>>>     8016601 Unable to build hsx24 on Windows using project creator and
>>>             Visual Studio
>>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016601
>>>     https://jbs.oracle.com/bugs/browse/JDK-8016601
>>>
>>> Here are the HSX-25 webrev URLs:
>>>
>>> OpenJDK: http://cr.openjdk.java.net/~dcubed/8016601-webrev/0-hsx25/
>>> Internal: 
>>> http://javaweb.us.oracle.com/~ddaugher/8016601-webrev/0-hsx25/
>>>
>>> Testing:
>>> - JPRT windows_i586 and windows_x64 build and test
>>> - local windows_i586 cmd line builds for:
>>>   {OpenJDK, Oracle} x {Client, Server} VM x {product, debug, fastdebug}
>>> - local windows_i586 VS2010 builds for
>>>   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
>>> fastdebug}
>>> - local windows_x64 VS2010 builds for
>>>   {OpenJDK, Oracle} x {Client, Server, Tiered} VM x {product, debug, 
>>> fastdebug}
>>>   Thanks to Ron for doing the windows_x64 testing
>>>
>>> Gory details are below. As always, comments, questions and
>>> suggestions are welome.
>>>
>>> Dan
>>>
>>>
>>> Gory Details:
>>>
>>> Build fixes:
>>> - VS2010 IDE builds are working again; fixes this failure mode:
>>>
>>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\objectCountEventSender.obj 
>>> : warning LNK4042: object specified more than once; extras ignored
>>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\errorReporter.obj 
>>> : warning LNK4042: object specified more than once; extras ignored
>>> 1>     Creating library 
>>> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.lib 
>>> and object 
>>> D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.exp
>>> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
>>> "public: static void __cdecl 
>>> ObjectCountEventSender::disable_requestable_event(void)" 
>>> (?disable_requestable_event at ObjectCountEventSender@@SAXXZ) 
>>> referenced in function "public: virtual void __thiscall 
>>> VM_GC_SendObjectCountEvent::doit(void)" 
>>> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
>>> 1>jfrRequestables.obj : error LNK2019: unresolved external symbol 
>>> "public: static void __cdecl 
>>> ObjectCountEventSender::enable_requestable_event(void)" 
>>> (?enable_requestable_event at ObjectCountEventSender@@SAXXZ) referenced 
>>> in function "public: virtual void __thiscall 
>>> VM_GC_SendObjectCountEvent::doit(void)" 
>>> (?doit at VM_GC_SendObjectCountEvent@@UAEXXZ)
>>> 1>D:\hotspot_src\hsx\24\hotspot_14_jun\build\vs-i486\compiler2\debug\jvm.dll 
>>> : fatal error LNK1120: 2 unresolved externals
>>>
>>> - The ProjectCreator tool is modified to support two new options:
>>>   '-relativeAltSrcInclude' and '-altRelativeInclude'. Here's an
>>>   example use of the new options:
>>>
>>>       -relativeAltSrcInclude src\closed
>>>       -altRelativeInclude share\vm
>>>
>>>   which means config the project with some alternate source files in
>>>   src\closed\share\vm that will replace the corresponding files in
>>>   src\share\vm.
>>>
>>>   For example, src\closed\share\vm\utilities\errorReporter.cpp replaces
>>>   src\share\vm\utilities\errorReporter.cpp. In the VS2010 IDE, you'll
>>>   still be able to see src\share\vm\utilities\errorReporter.cpp in the
>>>   project source browser, but the icon will indicate that the file is
>>>   excluded from the project.
>>>
>>>   The ProjectCreator tool's file tree walking logic is modified to keep
>>>   track of each alternate source file that is found. If a corresponding
>>>   regular source file is found, then the regular source file is
>>>   excluded from the project in favor of the alternate source version.
>>>
>>> - VS2010 cmd line build no longer issue the following linker warnings:
>>>
>>>     link.exe @C:\Users\lfoltan\AppData\Local\Temp\nm9B65.tmp
>>>     errorReporter.obj : warning LNK4042: object specified more than 
>>> once; extras ignored
>>>     objectCountEventSender.obj : warning LNK4042: object specified 
>>> more than once; extras ignored
>>>
>>> Misc cleanups:
>>>
>>> - removed more "core" config support from various makefiles and 
>>> scripts;
>>>   the "core" config is vestigal and was mostly removed years ago; the
>>>   "core" config is not the same as the "minimalvm" config.
>>> - removed extra references to ${ALTSRC}/share/vm/jfr objects
>>> - added some "AltSrc" versus "OpenJDK" identification to messages where
>>>   files are auto-generated
>>> - added some missing copyright headers
>>>
>>
>


From harold.seigel at oracle.com  Wed Aug  7 08:34:54 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 07 Aug 2013 11:34:54 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <52002E68.6080901@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
	<52002E68.6080901@oracle.com>
Message-ID: <5202691E.6020500@oracle.com>

Hi Vladimir,

Thanks for the thorough review!

See comments inline.

Harold

On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
> Harold,
>
> I don't like to have two versions of reinit_heapbase() method. Can you 
> modify the original one by checking (Universe::heap() != NULL)?
Done.  See next webrev.
>
> Note, on SPARC set() could generate up to 8 instructions to load 
> 64-bit constant into register. So I am not sure that it will be faster 
> than load.
We thought it would be faster because it doesn't need to load anything 
from memory.
>
> sparc MacroAssembler::decode_klass_not_null(Register src, Register 
> dst) should be modified to not use G6 when narrow_klass_shift() == 0.
Done.
>
> x86 MacroAssembler::encode_klass_not_null(Register dst, Register src) 
> also should be modified to not use R12 when dst != src by using 
> mov64(dst, base) + negq(dst) + addq(dst, src) instructions.
Done.
>
> Replace next leaq() with addq(dst, src) (address expressions use adr 
> module in cpu which could be bottleneck):
>
> 5135     } else {
> 5136       leaq(dst, Address(dst, src, Address::times_1, 0));
Done.
>
>
> I can't find where in CDS you store information about compressed klass 
> pointers and compressed oops parameters which were used during dump?
> How you verify that correct parameters/flags are ussed when such CDS 
> is used later?
No compressed klass pointers nor compressed oops get written to the 
archive.  So, the compressed klass pointers and compressed oops 
parameters do not need to be recorded in the archive.
>
> Could you add more explanation in the comment why next method returns 
> 'false' if DumpSharedSpaces is 'true'? From first glance it 
> contradicts to the bug's synopsis:
>
> +  // Return TRUE only if UseCompressedKlassPointers is True and 
> DumpSharedSpaces is False.
> +  static bool using_class_space() {
> +    return NOT_LP64(false) LP64_ONLY(UseCompressedKlassPointers && 
> !DumpSharedSpaces);
> +  }
The classes that are written to the read/write archive section are not 
from class metaspace.  Class metaspace is not dumped to the archive.
>
> Could you move set_narrow_klass_base_and_shift() near 
> can_use_cds_with_metaspace_addr() to use one #ifdef LP64?
Done.
>
> set_narrow_klass_base_and_shift() and 
> can_use_cds_with_metaspace_addr() have the same code for 
> UseSharedSpaces. It would be nice to have only one copy. Call 
> can_use_cds_with_metaspace_addr() from 
> set_narrow_klass_base_and_shift() ?
I could add new inlined methods that determine the higher_address and 
lower_base when UseSharedSpaces is true and have them called from 
set_narrow_klass_base_and_shift() and 
can_use_cds_with_metaspace_addr().  Would that be worth doing?
>
> I see that you unconditionally set comp klass ptr base and shift for 
> DumpSharedSpaces. Should you do the check similar to 
> can_use_cds_with_metaspace_addr() to find if you can do that? You 
> don't even check UseCompressedKlassPointers.
I don't think the checks are needed because the information written to 
the archive is not affected by the size of the class metaspace.

Also, I recently added code to arguments.cpp that will generate an error 
if UseCompressedOops or UseCompressedKlassPointers is turned off and 
DumpSharedSpaces is on.
>
> Why you have next limitation? What if coop can't be used because of 
> big heap?:
>
> +     // UseCompressedOops and UseCompressedKlassPointers must be on 
> for UseSharedSpaces.
> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
> +       no_shared_spaces();
If coop is turned off then CDS cannot be used.  CDS will only be 
supported if both UseCompressedOops and UseCompressedKlassPointers are 
TRUE.
>
> Could you move UseCompressedKlassPointers code in arguments.cpp into 
> separate method similar to set_use_compressed_oops()?
Done.
>
> About new tests.
> The first test in CDSCompressedKPtrsError misses 
> -XX:+UseCompressedOops flag.
Fixed.
>
> Could you also test cross flags combinations?:
>
> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
Done.
>
> It would be nice to have test to check ClassMetaspaceSize value range. 
> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint 
> or maxuint.
A member of our runtime SQE group is writing additional tests.  I'll ask 
him to write a ClassMetaspaceSize range test.

We chose 3Gb because we thought it was a sufficiently large size.
>
>
> About code style, indention. We align next line to corresponding part 
> of previous line if we need to split a line. And sometimes it is 
> better to keep one long line. I understand some of them were before 
> your changes but, please, clean up at lest ones you touched.
Done.
>
> Cases in metaspace.cpp:
>
> 2263   assert(raw_word_size >= min_size,
> 2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<" 
> SIZE_FORMAT, word_size, min_size));
>
>
> 2485   if (Metaspace::using_class_space() &&
> 2486     (Metaspace::class_space_list() != NULL)) {
>
>
> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
> 2575                       (Metaspace::using_class_space() ?
> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
> 2577 Metaspace::space_list()->virtual_space_total();
>
>
> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) " 
> SIZE_FORMAT ", "
> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT ", "
> 2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT 
> ", "
> 2697                            "large count " SIZE_FORMAT,
> 2698              cls_specialized_count, cls_specialized_waste,
> 2699              cls_small_count, cls_small_waste,
> 2700              cls_medium_count, cls_medium_waste, 
> cls_humongous_count);
>
>
> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G > addr) &&
> 2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>
>
> 2889         vm_exit_during_initialization(err_msg(
> 2890           "Could not allocate metaspace: %d bytes",
> 2891           class_metaspace_size()));
>
>
> 3107     return using_class_space() ?
> 3108       class_vsm()->sum_used_in_chunks_in_use() : 0;
>
>
> 3157     if (is_class && using_class_space()) {
> 3158        class_vsm()->deallocate(ptr, word_size);
>
>
> 3305   return space_list()->contains(ptr) ||
> 3306     (using_class_space() && class_space_list()->contains(ptr));
>
> metaspace.hpp:
>
>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
>  271       (Metaspace::using_class_space() ?
>  272         _allocated_capacity_words[Metaspace::ClassType] : 0);
>
>  285     return _allocated_used_words[Metaspace::NonClassType] +
>  286       (Metaspace::using_class_space() ?
>  287         _allocated_used_words[Metaspace::ClassType] : 0);
>
> universe.cpp:
>
>  849   assert((intptr_t)Universe::narrow_oop_base() <= 
> (intptr_t)(Universe::heap()->base() -
>  850     os::vm_page_size()) ||
>  851            Universe::narrow_oop_base() == NULL, "invalid value");
>
>
> Thanks,
> Vladimir
>
> On 8/2/13 1:31 PM, harold seigel wrote:
>> Hi,
>>
>> Please review this updated webrev for bug 8003424:
>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>
>> The updated webrev has a lot of changes from the previous webrev,
>> including the following:
>>
>>     1. Class metaspace information is now output when
>>     -XX:+PrintCompressedOopsMode is specified.
>>
>>     2. decode_klass_not_null(Register dst, Register src) no longer
>>     clobbers R12.
>>
>>     3. Method using_class_vsm() was renamed to using_class_space().
>>
>>     4. Type narrowKlass was added and replaces narrowOop, where 
>> appropriate.
>>
>>     5. The Metaspace:: qualifier was removed, where it was unnecessary.
>>
>>     6. Metaspace::initialize_class_space() was made private.
>>
>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was 
>> updated.
>>
>> Performance tests were run by Jenny using specjvm2008, specjbb2005, and
>> specjbb2013.  The results showed no significant performance difference
>> in terms of scores and gc behavior.
>>
>> Additional testing was done on Solaris Sparc and Linux x86 using
>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>
>> Please let me know what additional tests should be run.
>>
>> Thanks!
>> Harold
>>
>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>> Hi Harold,
>>>
>>> > Usually the narrow_klass_base will be 32G and the
>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means 
>>> that
>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12, 
>>> unless
>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that make
>>> sense?
>>>
>>> My bad, I miscalculated. But we have "perfect value" 0x800000000 and I
>>> am tempted to use may be bts (bit set) to avoid R12 usage (assuming or
>>> with check that class metaspace size < 32Gb).
>>>
>>> > Is there one prefix byte per instruction, or just for certain
>>> instructions?
>>>
>>> "Not all instructions require a REX prefix in 64-bit mode. A prefix is
>>> necessary only if an instruction references one of the extended
>>> registers or uses a 64-bit operand."
>>>
>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and =32
>>> and big java heap. Recently we got several bugs which indicated that
>>> we did not separate cleanly oops and klass pointers en/decoding.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>> Hi Vladimir,
>>>>
>>>> Thank you for the review!  Please see inline comments.
>>>>
>>>> Thanks, Harold
>>>>
>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>> Nice clean up, Harold
>>>>>>
>>>>>> Could you add the size of class metaspace in output with
>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>>>> remember an
>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>> Will be done in next webrev.
>>>>>>
>>>>>> Also it would be nice to print these info line (and compressed oops
>>>>>> info
>>>>>> line) in hs_err files.
>>>> I filed an enhancement bug for this: 8021264
>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>
>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in 
>>>>>> x86_64.ad.
>>>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also note
>>>>>> that code in .ad file does not check the encoding mode for narrow
>>>>>> klass/oop so it should be conservative and assume that arithmetic
>>>>>> instructions are used.
>>>> OK. Thanks.
>>>>>>
>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>>>>>> 4Gb so
>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>> encoding/decoding without destroying R12.
>>>>>
>>>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>> But the base will normally be 32Gb.  So this case won't happen very
>>>> often.
>>>>>
>>>>> You definitely should not use R12 in decode_klass_not_null(Register
>>>>> dst, Register src) method where you have free 'dst' register.
>>>> Will be fixed in next webrev.
>>>>>
>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>
>>>>> decode:
>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>   }
>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>> }
>>>>>
>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>>>> (max positive int).
>>>> Usually the narrow_klass_base will be 32G and the
>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means 
>>>> that
>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12, 
>>>> unless
>>>> we do multiple addq(r, narrow_klass_base_shifted()).  Does that make
>>>> sense?
>>>>>
>>>>> And you have general memory reservation problem. At least on Solaris,
>>>>> as I remember, OS will always try to keep protected 4Kb pages between
>>>>> different requested memory regions. That is why in jdk7 we first
>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>> compressed oops.
>>>>>
>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>> address or CompressedKlassPointersBase without CDS and with 
>>>>> compressed
>>>>> oops and with Xmx20Gb.
>>>> I verifed that we get either cds_address+cds_total as the address, or
>>>> CompressedKlassPointersBase as the address without CDS on Linux, 
>>>> Windows
>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap sizes and
>>>> -Xmx32G.
>>>>
>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the 
>>>> desired
>>>> CDS address for class metaspace regardless of heap size.
>>>>>
>>>>>>
>>>>>> instr_size_for_decode_klass_not_null() is ugly but unfortunately we
>>>>>> can't do other way. I assume you use max size because depending on
>>>>>> registers used in instructions you will or will not get prefix byte
>>>>>> (r8-r15).
>>>> Is there one prefix byte per instruction, or just for certain
>>>> instructions?
>>>>>>
>>>>>> I will look on changes in more details may be late.
>>>>>
>>>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>>>> which are not obvious.
>>>> I changed using_class_vsm() to using_class_space().
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review this fix for bug 8003424.
>>>>>>>
>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>> Open bug links at:
>>>>>>>
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>
>>>>>>> JBS Bug links at
>>>>>>>
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>
>>>>>>>
>>>>>>> This fix provides support for using compressed klass pointers with
>>>>>>> CDS.
>>>>>>> It also changes the class metaspace allocation on 64-bit platforms
>>>>>>> when
>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the 
>>>>>>> class
>>>>>>> metaspace as part of the Java Heap allocation and locating it at 
>>>>>>> the
>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>> separately,
>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>> metaspace
>>>>>>> because it won't be backed up against the Java heap. If CDS is 
>>>>>>> being
>>>>>>> used, then the CDS region will be allocated between the Java 
>>>>>>> heap and
>>>>>>> the metaspace.
>>>>>>>
>>>>>>> The new class metaspace allocation code tries to allocate memory at
>>>>>>> 32G,
>>>>>>> or above the CDS region, if it is present.  Because of this, 
>>>>>>> encoding
>>>>>>> and decoding of compressed klass pointers will always require use
>>>>>>> of a
>>>>>>> base register.  So, encoding and decoding of compressed klass
>>>>>>> pointers
>>>>>>> will differ from compressed oops.
>>>>>>>
>>>>>>> There are no class metaspace allocation changes if
>>>>>>> UseCompressedKlassPointers is turned off or if running on a 32-bit
>>>>>>> platform.
>>>>>>>
>>>>>>> The code changes also include some cleanup and will fix bugs 
>>>>>>> 8016729,
>>>>>>> 8011610, and 8003424.
>>>>>>>
>>>>>>>
>>>>>>> Many of the modules in this webrev contain a lot of changes. 
>>>>>>> Modules
>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were changed to
>>>>>>> support the new encoding and decoding of compressed klass pointers.
>>>>>>>
>>>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>>>> allocation for metaspace and the CDS region and to determine
>>>>>>> compressed
>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>
>>>>>>> Most of the changes to module universe.cpp were to remove code
>>>>>>> related
>>>>>>> to allocating metaspace and remove code that considered compressed
>>>>>>> klass
>>>>>>> pointers when determining the compressed oops compression 
>>>>>>> mechanism.
>>>>>>>
>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as part 
>>>>>>> of a
>>>>>>> cleanup requested by Coleen.
>>>>>>>
>>>>>>>
>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg tests,
>>>>>>> JPRT,
>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>>>> tests.  Most of the test were run with -Xshare:on and -Xshare:off
>>>>>>> (with
>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>>>> 64-Bit
>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests 
>>>>>>> were
>>>>>>> run on Solaris x86.
>>>>>>>
>>>>>>> The performance impact of these changes is TBD.
>>>>>>>
>>>>>>> Thanks, Harold
>>>>>>>
>>>>>>>
>>>>
>>


From vladimir.kozlov at oracle.com  Wed Aug  7 09:20:28 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 07 Aug 2013 09:20:28 -0700
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <52023770.9070804@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
	<51FFFB29.9070304@oracle.com> <52023770.9070804@oracle.com>
Message-ID: <520273CC.2060002@oracle.com>

 >> *+   if (PrintCompressedOopsMode || (PrintMiscellaneous && Verbose)) {*
 >> *+     gclog_or_tty->print_cr("Narrow klass base: " PTR_FORMAT ", Narrow klass shift: " SIZE_FORMAT,*
 >>
 >> I see this conditional comes from universe.cpp but I don't see why this should be printed for the OR condition:
 >> PrintMiscellaneous && Verbose.
 > I removed the second OR condition.

I asked Harold to do that because we print information about coop info with (PrintMiscellaneous && Verbose):

[SafePoint Polling address: 0x00000001106d5000]
Logical CPUs per core: 2
UseSSE=4  UseAVX=1  UseAES=1
Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 bytes
PrefetchCopyIntervalInBytes 576
PrefetchScanIntervalInBytes 576
PrefetchFieldsAhead 1
CPU:total 8 (4 cores per cpu, 2 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, 
ssse3, sse4.1, sse4.2, popcnt, avx, aes, ht, tsc, tscinvbit

heap address: 0x00000007ada00000, size: 1318 MB, zero based Compressed Oops


I wanted to avoid specifying additional flag -XX:+PrintCompressedOopsMode :)

Thanks,
Vladimir


On 8/7/13 5:02 AM, harold seigel wrote:
> Hi Coleen,
>
> Thanks for all the comments.  Please see my replies inline.
>
> Harold
>
> On 8/5/2013 3:21 PM, Coleen Phillimore wrote:
>>
>> On 08/02/2013 04:31 PM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this updated webrev for bug 8003424: http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>
>>> The updated webrev has a lot of changes from the previous webrev, including the following:
>>>
>>>     1. Class metaspace information is now output when -XX:+PrintCompressedOopsMode is specified.
>>>
>>>     2. decode_klass_not_null(Register dst, Register src) no longer clobbers R12.
>>>
>>
>> If decode_klass_not_null(src, dest) doesn't use r12, isn't the size calculated by
>> *instr_size_for_decode_klass_not_null* now wrong?   Or is this size calculation only valid for the case where you only
>> have one register?  Or can this size be a max size?
> This size is a max size.
>>
>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/src/share/vm/memory/heap.cpp.frames.html
>>
>> In this file can you spell out segm_r_aligned to something more descriptive - like reserved_segment_alignment,
>> reserved_segments_size, committed_segments_size.
> This change will be in the next webrev.
>>
>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/src/share/vm/memory/metaspace.cpp.udiff.html
>>
>> *+   if (PrintCompressedOopsMode || (PrintMiscellaneous && Verbose)) {*
>> *+     gclog_or_tty->print_cr("Narrow klass base: " PTR_FORMAT ", Narrow klass shift: " SIZE_FORMAT,*
>>
>> I see this conditional comes from universe.cpp but I don't see why this should be printed for the OR condition:
>> PrintMiscellaneous && Verbose.
> I removed the second OR condition.
>>
>> 2941 #ifdef _LP64
>> 2942     Universe::set_narrow_klass_base((address)_space_list->current_virtual_space()->bottom()
>>
>> Put a comment why you do this.  It's so UseCompressedKlassPointers decoding "works" while you are creating the shared
>> archive.  The oops are thrown away right now so it doesn't matter that the encoded value uses a different base during
>> dumping than it will use during UseSharedSpaces.   When we share String oops, we'll have to fix this code but I don't
>> know how to fix this yet. Maybe add code that always requires that the CDS archive base is the lower of the two
>> bases.   Not a problem with your code.
>>
>> Maybe you should assert that UseCompressedOops and KlassPtrs are set here though.
> I added both a comment and an assert.
>>
>> 3012   if (using_class_space()) {
>> 3013     _class_space_list = new VirtualSpaceList(rs);
>> 3014   }
>>
>> This function initialize_class_space() is always called when you are using_class_space() so why this conditional?
>> Shouldn't this also be moved to 2917 under where it's called (or above) in the ifdef LP64 since it's LP64 only now?
> I changed the conditional to an assert.
>>
>> 2557   if ((mdtype == Metaspace::ClassType) && !Metaspace::using_class_space()) {
>> 2558     return 0;
>> 2559   }
>> One way to shorten this expression that appears a few times, is to add an inlined overloaded
>> using_class_space(MetadataType).
> I'd prefer to leave this code as is.  This expression occurs only twice and I think the existing code is more
> descriptive than a new function would be.
>>
>> This looks really good.  I've been through it a few times and I don't see any problems, other than these suggestions here.
>>
>> Thanks!
>> Coleen
>>
>>>
>>>     3. Method using_class_vsm() was renamed to using_class_space().
>>>
>>>     4. Type narrowKlass was added and replaces narrowOop, where appropriate.
>>>
>>>     5. The Metaspace:: qualifier was removed, where it was unnecessary.
>>>
>>>     6. Metaspace::initialize_class_space() was made private.
>>>
>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was updated.
>>>
>>> Performance tests were run by Jenny using specjvm2008, specjbb2005, and specjbb2013.  The results showed no
>>> significant performance difference in terms of scores and gc behavior.
>>>
>>> Additional testing was done on Solaris Sparc and Linux x86 using SpecJBB2005 with -Xmx34g and
>>> -XX:ObjectAlignmentInBytes=16 & 32.
>>>
>>> Please let me know what additional tests should be run.
>>>
>>> Thanks!
>>> Harold
>>>
>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>> Hi Harold,
>>>>
>>>> > Usually the narrow_klass_base will be 32G and the
>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means that
>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12, unless
>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that make sense?
>>>>
>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000 and I am tempted to use may be bts (bit set) to
>>>> avoid R12 usage (assuming or with check that class metaspace size < 32Gb).
>>>>
>>>> > Is there one prefix byte per instruction, or just for certain instructions?
>>>>
>>>> "Not all instructions require a REX prefix in 64-bit mode. A prefix is necessary only if an instruction references
>>>> one of the extended registers or uses a 64-bit operand."
>>>>
>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and =32 and big java heap. Recently we got several bugs
>>>> which indicated that we did not separate cleanly oops and klass pointers en/decoding.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>> Hi Vladimir,
>>>>>
>>>>> Thank you for the review!  Please see inline comments.
>>>>>
>>>>> Thanks, Harold
>>>>>
>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>>> Nice clean up, Harold
>>>>>>>
>>>>>>> Could you add the size of class metaspace in output with
>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to remember an
>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>>> Will be done in next webrev.
>>>>>>>
>>>>>>> Also it would be nice to print these info line (and compressed oops info
>>>>>>> line) in hs_err files.
>>>>> I filed an enhancement bug for this: 8021264
>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>>
>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in x86_64.ad.
>>>>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also note
>>>>>>> that code in .ad file does not check the encoding mode for narrow
>>>>>>> klass/oop so it should be conservative and assume that arithmetic
>>>>>>> instructions are used.
>>>>> OK. Thanks.
>>>>>>>
>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below 4Gb so
>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>>> encoding/decoding without destroying R12.
>>>>>>
>>>>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>>> But the base will normally be 32Gb.  So this case won't happen very often.
>>>>>>
>>>>>> You definitely should not use R12 in decode_klass_not_null(Register
>>>>>> dst, Register src) method where you have free 'dst' register.
>>>>> Will be fixed in next webrev.
>>>>>>
>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>>
>>>>>> decode:
>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>>   }
>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>> }
>>>>>>
>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>>>>> (max positive int).
>>>>> Usually the narrow_klass_base will be 32G and the
>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means that
>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12, unless
>>>>> we do multiple addq(r, narrow_klass_base_shifted()).  Does that make sense?
>>>>>>
>>>>>> And you have general memory reservation problem. At least on Solaris,
>>>>>> as I remember, OS will always try to keep protected 4Kb pages between
>>>>>> different requested memory regions. That is why in jdk7 we first
>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>>> compressed oops.
>>>>>>
>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>>> address or CompressedKlassPointersBase without CDS and with compressed
>>>>>> oops and with Xmx20Gb.
>>>>> I verifed that we get either cds_address+cds_total as the address, or
>>>>> CompressedKlassPointersBase as the address without CDS on Linux, Windows
>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap sizes and
>>>>> -Xmx32G.
>>>>>
>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the desired
>>>>> CDS address for class metaspace regardless of heap size.
>>>>>>
>>>>>>>
>>>>>>> instr_size_for_decode_klass_not_null() is ugly but unfortunately we
>>>>>>> can't do other way. I assume you use max size because depending on
>>>>>>> registers used in instructions you will or will not get prefix byte
>>>>>>> (r8-r15).
>>>>> Is there one prefix byte per instruction, or just for certain instructions?
>>>>>>>
>>>>>>> I will look on changes in more details may be late.
>>>>>>
>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>>>>> which are not obvious.
>>>>> I changed using_class_vsm() to using_class_space().
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review this fix for bug 8003424.
>>>>>>>>
>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>>> Open bug links at:
>>>>>>>>
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>>
>>>>>>>> JBS Bug links at
>>>>>>>>
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>>
>>>>>>>>
>>>>>>>> This fix provides support for using compressed klass pointers with CDS.
>>>>>>>> It also changes the class metaspace allocation on 64-bit platforms when
>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the class
>>>>>>>> metaspace as part of the Java Heap allocation and locating it at the
>>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>>> separately,
>>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>>> metaspace
>>>>>>>> because it won't be backed up against the Java heap. If CDS is being
>>>>>>>> used, then the CDS region will be allocated between the Java heap and
>>>>>>>> the metaspace.
>>>>>>>>
>>>>>>>> The new class metaspace allocation code tries to allocate memory at
>>>>>>>> 32G,
>>>>>>>> or above the CDS region, if it is present.  Because of this, encoding
>>>>>>>> and decoding of compressed klass pointers will always require use of a
>>>>>>>> base register.  So, encoding and decoding of compressed klass pointers
>>>>>>>> will differ from compressed oops.
>>>>>>>>
>>>>>>>> There are no class metaspace allocation changes if
>>>>>>>> UseCompressedKlassPointers is turned off or if running on a 32-bit
>>>>>>>> platform.
>>>>>>>>
>>>>>>>> The code changes also include some cleanup and will fix bugs 8016729,
>>>>>>>> 8011610, and 8003424.
>>>>>>>>
>>>>>>>>
>>>>>>>> Many of the modules in this webrev contain a lot of changes. Modules
>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were changed to
>>>>>>>> support the new encoding and decoding of compressed klass pointers.
>>>>>>>>
>>>>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>>>>> allocation for metaspace and the CDS region and to determine compressed
>>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>>
>>>>>>>> Most of the changes to module universe.cpp were to remove code related
>>>>>>>> to allocating metaspace and remove code that considered compressed
>>>>>>>> klass
>>>>>>>> pointers when determining the compressed oops compression mechanism.
>>>>>>>>
>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as part of a
>>>>>>>> cleanup requested by Coleen.
>>>>>>>>
>>>>>>>>
>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg tests,
>>>>>>>> JPRT,
>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>>>>> tests.  Most of the test were run with -Xshare:on and -Xshare:off (with
>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>>>>> 64-Bit
>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests were
>>>>>>>> run on Solaris x86.
>>>>>>>>
>>>>>>>> The performance impact of these changes is TBD.
>>>>>>>>
>>>>>>>> Thanks, Harold
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>>
>

From mikael.vidstedt at oracle.com  Wed Aug  7 09:28:40 2013
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 07 Aug 2013 09:28:40 -0700
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <52024E1A.4000908@oracle.com>
References: <5201886C.1030206@oracle.com> <52024E1A.4000908@oracle.com>
Message-ID: <520275B8.5010101@oracle.com>


Coleen,

Funny you should mention that, and since I fully agree with you I 
actually did prepare another version of the patch which is heavily 
inspired by the java_props_md.c implementation:

http://cr.openjdk.java.net/~mikael/webrevs/winvercleanup2/webrev/

I personally like this version better, but the one thing that held me 
back was the fact that I will basically want to dig up machines with all 
the different (supported) Windows versions and verify that the code is 
still correct in all cases. If you think this is the way to go I more 
than willing to will do so. Let me know what you think about the new 
version of the patch!

There's no real urgency here - I'd rather do it correct once than...

Cheers,
Mikael


On 2013-08-07 06:39, Coleen Phillimore wrote:
>
> It looks like the code under the case for all these releases, should 
> be different case statements for each, rather than these cascading 
> 'if' statements.  And make 1668-1673 a new function returning si.   So 
> if we have a new release, in general it will work because the default 
> will print out something.   But a better default would be lines 
> 1712-1717 which are dead code now.
>
> Sorry, I know it's simple and urgent but this seems to be getting 
> increasingly ugly.
>
> Thanks,
> Coleen
>
> On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>>
>> Please review the following change:
>>
>> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>>
>> The patch adds support to os_windows.cpp for recognizing the upcoming 
>> Windows versions: Windows 8.1 and Windows Server 2012 R2.
>>
>> The changed is based on the corresponding code on the JDK side[1][2][3].
>>
>> Thanks,
>> Mikael
>>
>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
>> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
>> [3] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>>
>


From ioi.lam at oracle.com  Wed Aug  7 10:01:41 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 07 Aug 2013 10:01:41 -0700
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <520275B8.5010101@oracle.com>
References: <5201886C.1030206@oracle.com> <52024E1A.4000908@oracle.com>
	<520275B8.5010101@oracle.com>
Message-ID: <52027D75.7050204@oracle.com>

Just a minor nit. I think it's better to keep the old variable name 
(osvi) so that the number of lines changed would be minimized.

For testability, good luck finding a Windows 3.1 :-)

How about splitting the function so that you have a

void os::win32::print_windows_version(outputStream* st, OSVERSIONINFOEX 
osvi)

Then, we can have a stand-alone test.exe that links to os_windows.obj 
and test it with all combinarions of osvi.

- Ioi

On 08/07/2013 09:28 AM, Mikael Vidstedt wrote:
>
> Coleen,
>
> Funny you should mention that, and since I fully agree with you I 
> actually did prepare another version of the patch which is heavily 
> inspired by the java_props_md.c implementation:
>
> http://cr.openjdk.java.net/~mikael/webrevs/winvercleanup2/webrev/
>
> I personally like this version better, but the one thing that held me 
> back was the fact that I will basically want to dig up machines with 
> all the different (supported) Windows versions and verify that the 
> code is still correct in all cases. If you think this is the way to go 
> I more than willing to will do so. Let me know what you think about 
> the new version of the patch!
>
> There's no real urgency here - I'd rather do it correct once than...
>
> Cheers,
> Mikael
>
>
> On 2013-08-07 06:39, Coleen Phillimore wrote:
>>
>> It looks like the code under the case for all these releases, should 
>> be different case statements for each, rather than these cascading 
>> 'if' statements.  And make 1668-1673 a new function returning si.   
>> So if we have a new release, in general it will work because the 
>> default will print out something.   But a better default would be 
>> lines 1712-1717 which are dead code now.
>>
>> Sorry, I know it's simple and urgent but this seems to be getting 
>> increasingly ugly.
>>
>> Thanks,
>> Coleen
>>
>> On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>>>
>>> Please review the following change:
>>>
>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>>>
>>> The patch adds support to os_windows.cpp for recognizing the 
>>> upcoming Windows versions: Windows 8.1 and Windows Server 2012 R2.
>>>
>>> The changed is based on the corresponding code on the JDK 
>>> side[1][2][3].
>>>
>>> Thanks,
>>> Mikael
>>>
>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
>>> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
>>> [3] 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130807/9aa93ece/attachment-0001.html 

From dmitry.samersoff at oracle.com  Wed Aug  7 10:24:11 2013
From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com)
Date: Wed, 07 Aug 2013 17:24:11 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8021771: warning stat64 is deprecated -
	when building on OSX 10.7.5
Message-ID: <20130807172416.1F0794868B@hg.openjdk.java.net>

Changeset: 195ff07bc7f6
Author:    dsamersoff
Date:      2013-08-07 19:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/195ff07bc7f6

8021771: warning stat64 is deprecated - when building on OSX 10.7.5
Summary: stat64 have to be replaced with stat
Reviewed-by: dholmes, kmo
Contributed-by: rednaxelafx at gmail.com

! src/os/bsd/vm/attachListener_bsd.cpp


From coleen.phillimore at oracle.com  Wed Aug  7 10:56:57 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 07 Aug 2013 13:56:57 -0400
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <520275B8.5010101@oracle.com>
References: <5201886C.1030206@oracle.com> <52024E1A.4000908@oracle.com>
	<520275B8.5010101@oracle.com>
Message-ID: <52028A69.8010207@oracle.com>


Mikael,

I do like your new version better but because you changed so much, it 
should be verified on all versions of windows.   Which you might not 
want to do.   My suggestion to make this code nicer (fix case stmt and 
outline common code) was really simple and I think can be verified by 
code inspection, which might be less work and easier to review.

Coleen

On 8/7/2013 12:28 PM, Mikael Vidstedt wrote:
>
> Coleen,
>
> Funny you should mention that, and since I fully agree with you I 
> actually did prepare another version of the patch which is heavily 
> inspired by the java_props_md.c implementation:
>
> http://cr.openjdk.java.net/~mikael/webrevs/winvercleanup2/webrev/
>
> I personally like this version better, but the one thing that held me 
> back was the fact that I will basically want to dig up machines with 
> all the different (supported) Windows versions and verify that the 
> code is still correct in all cases. If you think this is the way to go 
> I more than willing to will do so. Let me know what you think about 
> the new version of the patch!
>
> There's no real urgency here - I'd rather do it correct once than...
>
> Cheers,
> Mikael
>
>
> On 2013-08-07 06:39, Coleen Phillimore wrote:
>>
>> It looks like the code under the case for all these releases, should 
>> be different case statements for each, rather than these cascading 
>> 'if' statements.  And make 1668-1673 a new function returning si.   
>> So if we have a new release, in general it will work because the 
>> default will print out something.   But a better default would be 
>> lines 1712-1717 which are dead code now.
>>
>> Sorry, I know it's simple and urgent but this seems to be getting 
>> increasingly ugly.
>>
>> Thanks,
>> Coleen
>>
>> On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>>>
>>> Please review the following change:
>>>
>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>>>
>>> The patch adds support to os_windows.cpp for recognizing the 
>>> upcoming Windows versions: Windows 8.1 and Windows Server 2012 R2.
>>>
>>> The changed is based on the corresponding code on the JDK 
>>> side[1][2][3].
>>>
>>> Thanks,
>>> Mikael
>>>
>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
>>> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
>>> [3] 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>>>
>>
>


From harold.seigel at oracle.com  Wed Aug  7 13:27:58 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 07 Aug 2013 16:27:58 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <520273CC.2060002@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
	<51FFFB29.9070304@oracle.com> <52023770.9070804@oracle.com>
	<520273CC.2060002@oracle.com>
Message-ID: <5202ADCE.4020602@oracle.com>

Hi,

I restored the second OR condition so that the info will get printed 
with either PrintCompressedOopsMode OR (PrintMiscellaneous && Verbose).

Thanks, Harold

On 8/7/2013 12:20 PM, Vladimir Kozlov wrote:
> >> *+   if (PrintCompressedOopsMode || (PrintMiscellaneous && 
> Verbose)) {*
> >> *+     gclog_or_tty->print_cr("Narrow klass base: " PTR_FORMAT ", 
> Narrow klass shift: " SIZE_FORMAT,*
> >>
> >> I see this conditional comes from universe.cpp but I don't see why 
> this should be printed for the OR condition:
> >> PrintMiscellaneous && Verbose.
> > I removed the second OR condition.
>
> I asked Harold to do that because we print information about coop info 
> with (PrintMiscellaneous && Verbose):
>
> [SafePoint Polling address: 0x00000001106d5000]
> Logical CPUs per core: 2
> UseSSE=4  UseAVX=1  UseAES=1
> Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 bytes
> PrefetchCopyIntervalInBytes 576
> PrefetchScanIntervalInBytes 576
> PrefetchFieldsAhead 1
> CPU:total 8 (4 cores per cpu, 2 threads per core) family 6 model 42 
> stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, 
> sse4.2, popcnt, avx, aes, ht, tsc, tscinvbit
>
> heap address: 0x00000007ada00000, size: 1318 MB, zero based Compressed 
> Oops
>
>
> I wanted to avoid specifying additional flag 
> -XX:+PrintCompressedOopsMode :)
>
> Thanks,
> Vladimir
>
>
> On 8/7/13 5:02 AM, harold seigel wrote:
>> Hi Coleen,
>>
>> Thanks for all the comments.  Please see my replies inline.
>>
>> Harold
>>
>> On 8/5/2013 3:21 PM, Coleen Phillimore wrote:
>>>
>>> On 08/02/2013 04:31 PM, harold seigel wrote:
>>>> Hi,
>>>>
>>>> Please review this updated webrev for bug 8003424: 
>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>
>>>> The updated webrev has a lot of changes from the previous webrev, 
>>>> including the following:
>>>>
>>>>     1. Class metaspace information is now output when 
>>>> -XX:+PrintCompressedOopsMode is specified.
>>>>
>>>>     2. decode_klass_not_null(Register dst, Register src) no longer 
>>>> clobbers R12.
>>>>
>>>
>>> If decode_klass_not_null(src, dest) doesn't use r12, isn't the size 
>>> calculated by
>>> *instr_size_for_decode_klass_not_null* now wrong?   Or is this size 
>>> calculation only valid for the case where you only
>>> have one register?  Or can this size be a max size?
>> This size is a max size.
>>>
>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/src/share/vm/memory/heap.cpp.frames.html 
>>>
>>>
>>> In this file can you spell out segm_r_aligned to something more 
>>> descriptive - like reserved_segment_alignment,
>>> reserved_segments_size, committed_segments_size.
>> This change will be in the next webrev.
>>>
>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/src/share/vm/memory/metaspace.cpp.udiff.html 
>>>
>>>
>>> *+   if (PrintCompressedOopsMode || (PrintMiscellaneous && Verbose)) {*
>>> *+     gclog_or_tty->print_cr("Narrow klass base: " PTR_FORMAT ", 
>>> Narrow klass shift: " SIZE_FORMAT,*
>>>
>>> I see this conditional comes from universe.cpp but I don't see why 
>>> this should be printed for the OR condition:
>>> PrintMiscellaneous && Verbose.
>> I removed the second OR condition.
>>>
>>> 2941 #ifdef _LP64
>>> 2942 
>>> Universe::set_narrow_klass_base((address)_space_list->current_virtual_space()->bottom()
>>>
>>> Put a comment why you do this.  It's so UseCompressedKlassPointers 
>>> decoding "works" while you are creating the shared
>>> archive.  The oops are thrown away right now so it doesn't matter 
>>> that the encoded value uses a different base during
>>> dumping than it will use during UseSharedSpaces.   When we share 
>>> String oops, we'll have to fix this code but I don't
>>> know how to fix this yet. Maybe add code that always requires that 
>>> the CDS archive base is the lower of the two
>>> bases.   Not a problem with your code.
>>>
>>> Maybe you should assert that UseCompressedOops and KlassPtrs are set 
>>> here though.
>> I added both a comment and an assert.
>>>
>>> 3012   if (using_class_space()) {
>>> 3013     _class_space_list = new VirtualSpaceList(rs);
>>> 3014   }
>>>
>>> This function initialize_class_space() is always called when you are 
>>> using_class_space() so why this conditional?
>>> Shouldn't this also be moved to 2917 under where it's called (or 
>>> above) in the ifdef LP64 since it's LP64 only now?
>> I changed the conditional to an assert.
>>>
>>> 2557   if ((mdtype == Metaspace::ClassType) && 
>>> !Metaspace::using_class_space()) {
>>> 2558     return 0;
>>> 2559   }
>>> One way to shorten this expression that appears a few times, is to 
>>> add an inlined overloaded
>>> using_class_space(MetadataType).
>> I'd prefer to leave this code as is.  This expression occurs only 
>> twice and I think the existing code is more
>> descriptive than a new function would be.
>>>
>>> This looks really good.  I've been through it a few times and I 
>>> don't see any problems, other than these suggestions here.
>>>
>>> Thanks!
>>> Coleen
>>>
>>>>
>>>>     3. Method using_class_vsm() was renamed to using_class_space().
>>>>
>>>>     4. Type narrowKlass was added and replaces narrowOop, where 
>>>> appropriate.
>>>>
>>>>     5. The Metaspace:: qualifier was removed, where it was 
>>>> unnecessary.
>>>>
>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>
>>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was 
>>>> updated.
>>>>
>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005, 
>>>> and specjbb2013.  The results showed no
>>>> significant performance difference in terms of scores and gc behavior.
>>>>
>>>> Additional testing was done on Solaris Sparc and Linux x86 using 
>>>> SpecJBB2005 with -Xmx34g and
>>>> -XX:ObjectAlignmentInBytes=16 & 32.
>>>>
>>>> Please let me know what additional tests should be run.
>>>>
>>>> Thanks!
>>>> Harold
>>>>
>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>> Hi Harold,
>>>>>
>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which 
>>>>> means that
>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12, 
>>>>> unless
>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>> make sense?
>>>>>
>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000 
>>>>> and I am tempted to use may be bts (bit set) to
>>>>> avoid R12 usage (assuming or with check that class metaspace size 
>>>>> < 32Gb).
>>>>>
>>>>> > Is there one prefix byte per instruction, or just for certain 
>>>>> instructions?
>>>>>
>>>>> "Not all instructions require a REX prefix in 64-bit mode. A 
>>>>> prefix is necessary only if an instruction references
>>>>> one of the extended registers or uses a 64-bit operand."
>>>>>
>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and 
>>>>> =32 and big java heap. Recently we got several bugs
>>>>> which indicated that we did not separate cleanly oops and klass 
>>>>> pointers en/decoding.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>>> Hi Vladimir,
>>>>>>
>>>>>> Thank you for the review!  Please see inline comments.
>>>>>>
>>>>>> Thanks, Harold
>>>>>>
>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>>>> Nice clean up, Harold
>>>>>>>>
>>>>>>>> Could you add the size of class metaspace in output with
>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to 
>>>>>>>> remember an
>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>>>> Will be done in next webrev.
>>>>>>>>
>>>>>>>> Also it would be nice to print these info line (and compressed 
>>>>>>>> oops info
>>>>>>>> line) in hs_err files.
>>>>>> I filed an enhancement bug for this: 8021264
>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>>>
>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in 
>>>>>>>> x86_64.ad.
>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also 
>>>>>>>> note
>>>>>>>> that code in .ad file does not check the encoding mode for narrow
>>>>>>>> klass/oop so it should be conservative and assume that arithmetic
>>>>>>>> instructions are used.
>>>>>> OK. Thanks.
>>>>>>>>
>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base 
>>>>>>>> below 4Gb so
>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>>>> encoding/decoding without destroying R12.
>>>>>>>
>>>>>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>>>> But the base will normally be 32Gb.  So this case won't happen 
>>>>>> very often.
>>>>>>>
>>>>>>> You definitely should not use R12 in decode_klass_not_null(Register
>>>>>>> dst, Register src) method where you have free 'dst' register.
>>>>>> Will be fixed in next webrev.
>>>>>>>
>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>>>
>>>>>>> decode:
>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>>>   }
>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>>> }
>>>>>>>
>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>>>>>> (max positive int).
>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which 
>>>>>> means that
>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12, 
>>>>>> unless
>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>>> make sense?
>>>>>>>
>>>>>>> And you have general memory reservation problem. At least on 
>>>>>>> Solaris,
>>>>>>> as I remember, OS will always try to keep protected 4Kb pages 
>>>>>>> between
>>>>>>> different requested memory regions. That is why in jdk7 we first
>>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>>>> compressed oops.
>>>>>>>
>>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>>>> address or CompressedKlassPointersBase without CDS and with 
>>>>>>> compressed
>>>>>>> oops and with Xmx20Gb.
>>>>>> I verifed that we get either cds_address+cds_total as the 
>>>>>> address, or
>>>>>> CompressedKlassPointersBase as the address without CDS on Linux, 
>>>>>> Windows
>>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap 
>>>>>> sizes and
>>>>>> -Xmx32G.
>>>>>>
>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the 
>>>>>> desired
>>>>>> CDS address for class metaspace regardless of heap size.
>>>>>>>
>>>>>>>>
>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but 
>>>>>>>> unfortunately we
>>>>>>>> can't do other way. I assume you use max size because depending on
>>>>>>>> registers used in instructions you will or will not get prefix 
>>>>>>>> byte
>>>>>>>> (r8-r15).
>>>>>> Is there one prefix byte per instruction, or just for certain 
>>>>>> instructions?
>>>>>>>>
>>>>>>>> I will look on changes in more details may be late.
>>>>>>>
>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>>>>>> which are not obvious.
>>>>>> I changed using_class_vsm() to using_class_space().
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review this fix for bug 8003424.
>>>>>>>>>
>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>>>> Open bug links at:
>>>>>>>>>
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>>>
>>>>>>>>> JBS Bug links at
>>>>>>>>>
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This fix provides support for using compressed klass pointers 
>>>>>>>>> with CDS.
>>>>>>>>> It also changes the class metaspace allocation on 64-bit 
>>>>>>>>> platforms when
>>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the 
>>>>>>>>> class
>>>>>>>>> metaspace as part of the Java Heap allocation and locating it 
>>>>>>>>> at the
>>>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>>>> separately,
>>>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>>>> metaspace
>>>>>>>>> because it won't be backed up against the Java heap. If CDS is 
>>>>>>>>> being
>>>>>>>>> used, then the CDS region will be allocated between the Java 
>>>>>>>>> heap and
>>>>>>>>> the metaspace.
>>>>>>>>>
>>>>>>>>> The new class metaspace allocation code tries to allocate 
>>>>>>>>> memory at
>>>>>>>>> 32G,
>>>>>>>>> or above the CDS region, if it is present. Because of this, 
>>>>>>>>> encoding
>>>>>>>>> and decoding of compressed klass pointers will always require 
>>>>>>>>> use of a
>>>>>>>>> base register.  So, encoding and decoding of compressed klass 
>>>>>>>>> pointers
>>>>>>>>> will differ from compressed oops.
>>>>>>>>>
>>>>>>>>> There are no class metaspace allocation changes if
>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a 
>>>>>>>>> 32-bit
>>>>>>>>> platform.
>>>>>>>>>
>>>>>>>>> The code changes also include some cleanup and will fix bugs 
>>>>>>>>> 8016729,
>>>>>>>>> 8011610, and 8003424.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Many of the modules in this webrev contain a lot of changes. 
>>>>>>>>> Modules
>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were 
>>>>>>>>> changed to
>>>>>>>>> support the new encoding and decoding of compressed klass 
>>>>>>>>> pointers.
>>>>>>>>>
>>>>>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>>>>>> allocation for metaspace and the CDS region and to determine 
>>>>>>>>> compressed
>>>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>>>
>>>>>>>>> Most of the changes to module universe.cpp were to remove code 
>>>>>>>>> related
>>>>>>>>> to allocating metaspace and remove code that considered 
>>>>>>>>> compressed
>>>>>>>>> klass
>>>>>>>>> pointers when determining the compressed oops compression 
>>>>>>>>> mechanism.
>>>>>>>>>
>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as 
>>>>>>>>> part of a
>>>>>>>>> cleanup requested by Coleen.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg 
>>>>>>>>> tests,
>>>>>>>>> JPRT,
>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>>>>>> tests.  Most of the test were run with -Xshare:on and 
>>>>>>>>> -Xshare:off (with
>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>>>>>> 64-Bit
>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK 
>>>>>>>>> tests were
>>>>>>>>> run on Solaris x86.
>>>>>>>>>
>>>>>>>>> The performance impact of these changes is TBD.
>>>>>>>>>
>>>>>>>>> Thanks, Harold
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>>
>>


From calvin.cheung at oracle.com  Wed Aug  7 17:25:57 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Wed, 07 Aug 2013 17:25:57 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill PDF&Image
	Writer 10.0 Build 4
Message-ID: <5202E595.3090608@oracle.com>

Please review this small fix for fixing a fatal error in 
~ExceptionMark() triggered by ClassNotFoundException in 
ClassLoader::create_class_path_entry(). I could reproduce similar crash 
by trying to load a class from an empty jar which is in the 
bootclasspath. The following program can trigger the crash if the 
jce.jar is invalid (e.g. 0-byte):

public class TestForName {
     public static void main(String[] args) {
         try {
             Class cls = Class.forName("javax.crypto.KeyGenerator");
             System.out.println("Class = " + cls.getName());
         } catch (ClassNotFoundException cnfe) {
             cnfe.printStackTrace();
         }
     }
}

The fix also changes the assert() in LazyClassPathEntry::resolve_entry() 
to a NULL check. Otherwise, the assert() will fail under the above test 
scenario.

With the fix, the following ClassNotFoundException will be thrown 
instead of a crash:
java.lang.ClassNotFoundException: javax.crypto.KeyGenerator
         at java.net.URLClassLoader$1.run(URLClassLoader.java:365)
         at java.net.URLClassLoader$1.run(URLClassLoader.java:354)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:353)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
         at java.lang.Class.forName0(Native Method)
         at java.lang.Class.forName(Class.java:258)
         at TestForName.main(TestForName.java:6)

webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/

JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675
bug: http://bugs.sun.com/view_bug.do?bug_id=8020675

Tests:
     jprt, vm.quick.testlist

thanks,
Calvin



From david.holmes at oracle.com  Wed Aug  7 18:47:22 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 08 Aug 2013 11:47:22 +1000
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5202E595.3090608@oracle.com>
References: <5202E595.3090608@oracle.com>
Message-ID: <5202F8AA.3000105@oracle.com>

Hi Calvin,

It seems to me that this code has a general problem with exceptions. If 
exceptions can be posted then methods should be declared with a last 
parameter of TRAPS and called with a CHECK_ macro. The way this code is 
written it does not seem to expect any exceptions to be possible. I 
would check with Karen on this.

This addition seems unused:

+   Thread* THREAD = thread;

Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing 
exceptions - don't know what the thought process was there :)

David

On 8/08/2013 10:25 AM, Calvin Cheung wrote:
> Please review this small fix for fixing a fatal error in
> ~ExceptionMark() triggered by ClassNotFoundException in
> ClassLoader::create_class_path_entry(). I could reproduce similar crash
> by trying to load a class from an empty jar which is in the
> bootclasspath. The following program can trigger the crash if the
> jce.jar is invalid (e.g. 0-byte):
>
> public class TestForName {
>      public static void main(String[] args) {
>          try {
>              Class cls = Class.forName("javax.crypto.KeyGenerator");
>              System.out.println("Class = " + cls.getName());
>          } catch (ClassNotFoundException cnfe) {
>              cnfe.printStackTrace();
>          }
>      }
> }
>
> The fix also changes the assert() in LazyClassPathEntry::resolve_entry()
> to a NULL check. Otherwise, the assert() will fail under the above test
> scenario.
>
> With the fix, the following ClassNotFoundException will be thrown
> instead of a crash:
> java.lang.ClassNotFoundException: javax.crypto.KeyGenerator
>          at java.net.URLClassLoader$1.run(URLClassLoader.java:365)
>          at java.net.URLClassLoader$1.run(URLClassLoader.java:354)
>          at java.security.AccessController.doPrivileged(Native Method)
>          at java.net.URLClassLoader.findClass(URLClassLoader.java:353)
>          at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
>          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>          at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
>          at java.lang.Class.forName0(Native Method)
>          at java.lang.Class.forName(Class.java:258)
>          at TestForName.main(TestForName.java:6)
>
> webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>
> JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675
> bug: http://bugs.sun.com/view_bug.do?bug_id=8020675
>
> Tests:
>      jprt, vm.quick.testlist
>
> thanks,
> Calvin
>
>

From ioi.lam at oracle.com  Wed Aug  7 19:15:40 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 07 Aug 2013 19:15:40 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5202F8AA.3000105@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
Message-ID: <5202FF4C.3020705@oracle.com>

|JDK6 seems to handle this better. I have written a simple stand-alone 
test case that doesn't require truncating JAR files in the JDK:||
||
||=========================||
||/*||
||javac test2.java||
||rm -f foo.jar||
||java -cp . -Xbootclasspath/a:foo.jar test2||
||touch foo.jar||
||java -cp . -Xbootclasspath/a:foo.jar test2||
||*/||
||
||public class test2 {||
||    public static void main(String args[]) {||
||        try {||
||System.out.println(Class.forName("javax.crypto.MacSpi"));||
||            System.out.println(Class.forName("xxx"));||
||        } catch (Throwable t) {||
||            t.printStackTrace();||
||        }||
||    }||
||}||
||=========================||
| |
||JDK6 works fine, but JDK7 would crash with the second "java -cp . 
-Xbootclasspath/a:foo.jar test2" command.||
||
||So I think the correct fix is to restore the JDK6 behavior (not sure 
if it's already the same with your patch, but worth checking), and also 
add a new jtreg test into hotspot.||
||
||Thanks||
||- Ioi||
||
||On 08/07/2013 06:47 PM, David Holmes wrote:||
|
> |Hi Calvin, ||
> | |
> ||It seems to me that this code has a general problem with exceptions. 
> If exceptions can be posted then methods should be declared with a 
> last parameter of TRAPS and called with a CHECK_ macro. The way this 
> code is written it does not seem to expect any exceptions to be 
> possible. I would check with Karen on this. ||
> | |
> ||This addition seems unused: ||
> | |
> ||+   Thread* THREAD = thread; ||
> | |
> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing 
> exceptions - don't know what the thought process was there :) ||
> | |
> ||David ||
> | |
> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
> |
>> |Please review this small fix for fixing a fatal error in ||
>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>> ||ClassLoader::create_class_path_entry(). I could reproduce similar 
>> crash ||
>> ||by trying to load a class from an empty jar which is in the ||
>> ||bootclasspath. The following program can trigger the crash if the ||
>> ||jce.jar is invalid (e.g. 0-byte): ||
>> | |
>> ||public class TestForName { ||
>> ||     public static void main(String[] args) { ||
>> ||         try { ||
>> ||             Class cls = Class.forName("javax.crypto.KeyGenerator"); ||
>> ||             System.out.println("Class = " + cls.getName()); ||
>> ||         } catch (ClassNotFoundException cnfe) { ||
>> ||             cnfe.printStackTrace(); ||
>> ||         } ||
>> ||     } ||
>> ||} ||
>> | |
>> ||The fix also changes the assert() in 
>> LazyClassPathEntry::resolve_entry() ||
>> ||to a NULL check. Otherwise, the assert() will fail under the above 
>> test ||
>> ||scenario. ||
>> | |
>> ||With the fix, the following ClassNotFoundException will be thrown ||
>> ||instead of a crash: ||
>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>> ||         at java.security.AccessController.doPrivileged(Native 
>> Method) ||
>> ||         at 
>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>> ||         at 
>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>> ||         at java.lang.Class.forName0(Native Method) ||
>> ||         at java.lang.Class.forName(Class.java:258) ||
>> ||         at TestForName.main(TestForName.java:6) ||
>> | |
>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>> | |
>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>> | |
>> ||Tests: ||
>> ||     jprt, vm.quick.testlist ||
>> | |
>> ||thanks, ||
>> ||Calvin ||
>> | |
>> | |
>> |
|
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130807/ef26289b/attachment-0001.html 

From ioi.lam at oracle.com  Wed Aug  7 19:30:04 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 07 Aug 2013 19:30:04 -0700
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
In-Reply-To: <52023E89.3060706@oracle.com>
References: <52017AC9.9040809@oracle.com> <52023E89.3060706@oracle.com>
Message-ID: <520302AC.3000201@oracle.com>

Hi Yumin,

David is right. The problem is with the "if" in the shell script.

The fix in JDK-7107135 makes sure that, even after loading a "bad" DLL, 
Java's stack overflow check should still work.

Without the JDK-7107135, the JVM may crash, because stack overflow is no 
longer caught and Java writes into unallocated space above the top of 
the stack.

Therefore, the purpose of both Test.java and TestMT.java was to check 
for the crash. As long as no crash happens, the JVM should return the 
default 0 exit code. Any non-zero exit code means the VM has crashed and 
thus the test has failed.

Thanks
- Ioi

On 08/07/2013 05:33 AM, David Holmes wrote:
> Hi Yumin,
>
> As I understand the bug report the issue is more with the shell script 
> returning the value of $? which no longer refers to the execution of 
> the test but the evaluation of the if [ $? == 0 ]
>
> David
>
> On 7/08/2013 8:38 AM, Yumin Qi wrote:
>> Please review:
>>
>> http://cr.openjdk.java.net/~minqi/8019583/webrev0/
>> <http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>
>>
>> Summary: The test will always pass since TestMT.java will always return
>> value 0 to shell. Fix by recording failure value and exit with it.
>>
>> Thanks
>> Yumin


From calvin.cheung at oracle.com  Thu Aug  8 11:08:49 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 08 Aug 2013 11:08:49 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5202FF4C.3020705@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com>
Message-ID: <5203DEB1.9080808@oracle.com>

Hi Ioi, David,

On 8/7/2013 7:15 PM, Ioi Lam wrote:
> |JDK6 seems to handle this better. I have written a simple stand-alone 
> test case that doesn't require truncating JAR files in the JDK:||
> ||
> ||=========================||
> ||/*||
> ||javac test2.java||
> ||rm -f foo.jar||
> ||java -cp . -Xbootclasspath/a:foo.jar test2||
> ||touch foo.jar||
> ||java -cp . -Xbootclasspath/a:foo.jar test2||
> ||*/||
> ||
> ||public class test2 {||
> ||    public static void main(String args[]) {||
> ||        try {||
> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
> ||System.out.println(Class.forName("xxx"));||
> ||        } catch (Throwable t) {||
> ||            t.printStackTrace();||
> ||        }||
> ||    }||
> ||}||
> ||=========================||
> | |
> ||JDK6 works fine, but JDK7 would crash with the second "java -cp . 
> -Xbootclasspath/a:foo.jar test2" command.||
> |
|I saw crash with the latest 6 update release with both test cases.
The crash seems to be at the same spot.
|
> |||
> ||So I think the correct fix is to restore the JDK6 behavior (not sure 
> if it's already the same with your patch, but worth checking), and 
> also add a new jtreg test into hotspot.||
> |
|I checked the jdk 6 code and those 3 methods which I changed look the 
same as jdk 8.
Sure, I can add a jtreg test.
|
> |||
> ||Thanks||
> ||- Ioi||
> ||
> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
> |
>> |Hi Calvin, ||
>> | |
>> ||It seems to me that this code has a general problem with 
>> exceptions. If exceptions can be posted then methods should be 
>> declared with a last parameter of TRAPS and called with a CHECK_ 
>> macro. The way this code is written it does not seem to expect any 
>> exceptions to be possible. I would check with Karen on this. ||
>> |
|I was thinking about that but that would involves a bit more changes.
I can give it a try.
|
>> || |
>> ||This addition seems unused: ||
>> | |
>> ||+   Thread* THREAD = thread; ||
>> |
|It is required for the THROW_MSG().
It won't be needed if the method is declared with TRAPS as the last 
parameter (I think).

thanks,
Calvin
|
>> || |
>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing 
>> exceptions - don't know what the thought process was there :) ||
>> | |
>> ||David ||
>> | |
>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>> |
>>> |Please review this small fix for fixing a fatal error in ||
>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>> ||ClassLoader::create_class_path_entry(). I could reproduce similar 
>>> crash ||
>>> ||by trying to load a class from an empty jar which is in the ||
>>> ||bootclasspath. The following program can trigger the crash if the ||
>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>> | |
>>> ||public class TestForName { ||
>>> ||     public static void main(String[] args) { ||
>>> ||         try { ||
>>> ||             Class cls = 
>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>> ||             System.out.println("Class = " + cls.getName()); ||
>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>> ||             cnfe.printStackTrace(); ||
>>> ||         } ||
>>> ||     } ||
>>> ||} ||
>>> | |
>>> ||The fix also changes the assert() in 
>>> LazyClassPathEntry::resolve_entry() ||
>>> ||to a NULL check. Otherwise, the assert() will fail under the above 
>>> test ||
>>> ||scenario. ||
>>> | |
>>> ||With the fix, the following ClassNotFoundException will be thrown ||
>>> ||instead of a crash: ||
>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>> ||         at java.security.AccessController.doPrivileged(Native 
>>> Method) ||
>>> ||         at 
>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>> ||         at 
>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>> ||         at java.lang.Class.forName0(Native Method) ||
>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>> ||         at TestForName.main(TestForName.java:6) ||
>>> | |
>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>> | |
>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>> | |
>>> ||Tests: ||
>>> ||     jprt, vm.quick.testlist ||
>>> | |
>>> ||thanks, ||
>>> ||Calvin ||
>>> | |
>>> | |
>>> |
> |
> | 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130808/5208b7a5/attachment.html 

From coleen.phillimore at oracle.com  Thu Aug  8 11:24:01 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 08 Aug 2013 14:24:01 -0400
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5203DEB1.9080808@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
Message-ID: <5203E241.4040507@oracle.com>


I'm confused.   You saw a crash?

On 08/08/2013 02:08 PM, Calvin Cheung wrote:
> Hi Ioi, David,
>
> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>> |JDK6 seems to handle this better. I have written a simple 
>> stand-alone test case that doesn't require truncating JAR files in 
>> the JDK:||
>> ||
>> ||=========================||
>> ||/*||
>> ||javac test2.java||
>> ||rm -f foo.jar||
>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>> ||touch foo.jar||
>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>> ||*/||
>> ||
>> ||public class test2 {||
>> ||    public static void main(String args[]) {||
>> ||        try {||
>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>> ||System.out.println(Class.forName("xxx"));||
>> ||        } catch (Throwable t) {||
>> ||            t.printStackTrace();||
>> ||        }||
>> ||    }||
>> ||}||
>> ||=========================||
>> | |
>> ||JDK6 works fine, but JDK7 would crash with the second "java -cp . 
>> -Xbootclasspath/a:foo.jar test2" command.||
>> |
> |I saw crash with the latest 6 update release with both test cases.
> The crash seems to be at the same spot.
> |
>> |||
>> ||So I think the correct fix is to restore the JDK6 behavior (not 
>> sure if it's already the same with your patch, but worth checking), 
>> and also add a new jtreg test into hotspot.||
>> |
> |I checked the jdk 6 code and those 3 methods which I changed look the 
> same as jdk 8.
> Sure, I can add a jtreg test.
> |
>> |||
>> ||Thanks||
>> ||- Ioi||
>> ||
>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>> |
>>> |Hi Calvin, ||
>>> | |
>>> ||It seems to me that this code has a general problem with 
>>> exceptions. If exceptions can be posted then methods should be 
>>> declared with a last parameter of TRAPS and called with a CHECK_ 
>>> macro. The way this code is written it does not seem to expect any 
>>> exceptions to be possible. I would check with Karen on this. ||
>>> |
> |I was thinking about that but that would involves a bit more changes.
> I can give it a try.
> |
>>> || |
>>> ||This addition seems unused: ||
>>> | |
>>> ||+   Thread* THREAD = thread; ||
>>> |
> |It is required for the THROW_MSG().
> It won't be needed if the method is declared with TRAPS as the last 
> parameter (I think).
>
> thanks,
> Calvin
> |
>>> || |
>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing 
>>> exceptions - don't know what the thought process was there :) ||
>>> | |
>>> ||David ||
>>> | |
>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>> |
>>>> |Please review this small fix for fixing a fatal error in ||
>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>> ||ClassLoader::create_class_path_entry(). I could reproduce similar 
>>>> crash ||
>>>> ||by trying to load a class from an empty jar which is in the ||
>>>> ||bootclasspath. The following program can trigger the crash if the ||
>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>> | |
>>>> ||public class TestForName { ||
>>>> ||     public static void main(String[] args) { ||
>>>> ||         try { ||
>>>> ||             Class cls = 
>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>> ||             System.out.println("Class = " + cls.getName()); ||
>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>> ||             cnfe.printStackTrace(); ||
>>>> ||         } ||
>>>> ||     } ||
>>>> ||} ||
>>>> | |
>>>> ||The fix also changes the assert() in 
>>>> LazyClassPathEntry::resolve_entry() ||
>>>> ||to a NULL check. Otherwise, the assert() will fail under the 
>>>> above test ||
>>>> ||scenario. ||
>>>> | |
>>>> ||With the fix, the following ClassNotFoundException will be thrown ||
>>>> ||instead of a crash: ||
>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>> ||         at java.security.AccessController.doPrivileged(Native 
>>>> Method) ||
>>>> ||         at 
>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>> ||         at 
>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>> | |
>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>> | |
>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>> | |
>>>> ||Tests: ||
>>>> ||     jprt, vm.quick.testlist ||
>>>> | |
>>>> ||thanks, ||
>>>> ||Calvin ||
>>>> | |
>>>> | |
>>>> |
>> |
>> | 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130808/c5092bd4/attachment-0001.html 

From coleen.phillimore at oracle.com  Thu Aug  8 11:28:30 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 08 Aug 2013 14:28:30 -0400
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5203E241.4040507@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E241.4040507@oracle.com>
Message-ID: <5203E34E.8090502@oracle.com>


Sorry for the noise.  I thought this was the another thread.
Coleen

On 08/08/2013 02:24 PM, Coleen Phillimore wrote:
>
> I'm confused.   You saw a crash?
>
> On 08/08/2013 02:08 PM, Calvin Cheung wrote:
>> Hi Ioi, David,
>>
>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>> |JDK6 seems to handle this better. I have written a simple 
>>> stand-alone test case that doesn't require truncating JAR files in 
>>> the JDK:||
>>> ||
>>> ||=========================||
>>> ||/*||
>>> ||javac test2.java||
>>> ||rm -f foo.jar||
>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>> ||touch foo.jar||
>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>> ||*/||
>>> ||
>>> ||public class test2 {||
>>> ||    public static void main(String args[]) {||
>>> ||        try {||
>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>> ||System.out.println(Class.forName("xxx"));||
>>> ||        } catch (Throwable t) {||
>>> ||            t.printStackTrace();||
>>> ||        }||
>>> ||    }||
>>> ||}||
>>> ||=========================||
>>> | |
>>> ||JDK6 works fine, but JDK7 would crash with the second "java -cp . 
>>> -Xbootclasspath/a:foo.jar test2" command.||
>>> |
>> |I saw crash with the latest 6 update release with both test cases.
>> The crash seems to be at the same spot.
>> |
>>> |||
>>> ||So I think the correct fix is to restore the JDK6 behavior (not 
>>> sure if it's already the same with your patch, but worth checking), 
>>> and also add a new jtreg test into hotspot.||
>>> |
>> |I checked the jdk 6 code and those 3 methods which I changed look 
>> the same as jdk 8.
>> Sure, I can add a jtreg test.
>> |
>>> |||
>>> ||Thanks||
>>> ||- Ioi||
>>> ||
>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>> |
>>>> |Hi Calvin, ||
>>>> | |
>>>> ||It seems to me that this code has a general problem with 
>>>> exceptions. If exceptions can be posted then methods should be 
>>>> declared with a last parameter of TRAPS and called with a CHECK_ 
>>>> macro. The way this code is written it does not seem to expect any 
>>>> exceptions to be possible. I would check with Karen on this. ||
>>>> |
>> |I was thinking about that but that would involves a bit more changes.
>> I can give it a try.
>> |
>>>> || |
>>>> ||This addition seems unused: ||
>>>> | |
>>>> ||+   Thread* THREAD = thread; ||
>>>> |
>> |It is required for the THROW_MSG().
>> It won't be needed if the method is declared with TRAPS as the last 
>> parameter (I think).
>>
>> thanks,
>> Calvin
>> |
>>>> || |
>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing 
>>>> exceptions - don't know what the thought process was there :) ||
>>>> | |
>>>> ||David ||
>>>> | |
>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>> |
>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce 
>>>>> similar crash ||
>>>>> ||by trying to load a class from an empty jar which is in the ||
>>>>> ||bootclasspath. The following program can trigger the crash if the ||
>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>> | |
>>>>> ||public class TestForName { ||
>>>>> ||     public static void main(String[] args) { ||
>>>>> ||         try { ||
>>>>> ||             Class cls = 
>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>> ||             System.out.println("Class = " + cls.getName()); ||
>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>> ||             cnfe.printStackTrace(); ||
>>>>> ||         } ||
>>>>> ||     } ||
>>>>> ||} ||
>>>>> | |
>>>>> ||The fix also changes the assert() in 
>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>> ||to a NULL check. Otherwise, the assert() will fail under the 
>>>>> above test ||
>>>>> ||scenario. ||
>>>>> | |
>>>>> ||With the fix, the following ClassNotFoundException will be thrown ||
>>>>> ||instead of a crash: ||
>>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>>> ||         at 
>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>> ||         at 
>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>> ||         at java.security.AccessController.doPrivileged(Native 
>>>>> Method) ||
>>>>> ||         at 
>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>> ||         at 
>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>> | |
>>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>> | |
>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>> | |
>>>>> ||Tests: ||
>>>>> ||     jprt, vm.quick.testlist ||
>>>>> | |
>>>>> ||thanks, ||
>>>>> ||Calvin ||
>>>>> | |
>>>>> | |
>>>>> |
>>> |
>>> | 
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130808/9a647775/attachment.html 

From christian.tornqvist at oracle.com  Thu Aug  8 11:43:04 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 8 Aug 2013 14:43:04 -0400
Subject: Request for review: 7073961 [TESTBUG]
	closed/runtime/4845371/DBB.java	failed on solaris 10 x64
In-Reply-To: <51FAAE26.5030306@oracle.com>
References: <51FAAE26.5030306@oracle.com>
Message-ID: <00da01ce9467$1e29eed0$5a7dcc70$@oracle.com>

Change looks good, thanks for fixing this :)

Thanks,
Christian

-----Original Message-----
From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of harold seigel
Sent: den 1 augusti 2013 14:51
To: hotspot-runtime-dev at openjdk.java.net
Subject: Request for review: 7073961 [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 x64

Hi,

Please review this small change to help fix bug 7073961.  This change adds a method that enables tests to distinguish between Solaris on Sparc and Solaris on X86.

Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_7073961/
<http://cr.openjdk.java.net/%7Ehseigel/bug_7073961/>

Bug link at: http://bugs.sun.com/view_bug.do?bug_id=7073961

JBB Bug at: https://jbs.oracle.com/bugs/browse/JDK-7073961

Thanks!  Harold


From calvin.cheung at oracle.com  Thu Aug  8 11:45:03 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 08 Aug 2013 11:45:03 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5203E241.4040507@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E241.4040507@oracle.com>
Message-ID: <5203E72F.9080608@oracle.com>

On 8/8/2013 11:24 AM, Coleen Phillimore wrote:
>
> I'm confused.   You saw a crash?
The test cases triggered the following fatal() call in ~ExceptionMark():
     fatal("ExceptionMark destructor expects no pending exceptions");

Calvin

>
> On 08/08/2013 02:08 PM, Calvin Cheung wrote:
>> Hi Ioi, David,
>>
>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>> |JDK6 seems to handle this better. I have written a simple 
>>> stand-alone test case that doesn't require truncating JAR files in 
>>> the JDK:||
>>> ||
>>> ||=========================||
>>> ||/*||
>>> ||javac test2.java||
>>> ||rm -f foo.jar||
>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>> ||touch foo.jar||
>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>> ||*/||
>>> ||
>>> ||public class test2 {||
>>> ||    public static void main(String args[]) {||
>>> ||        try {||
>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>> ||System.out.println(Class.forName("xxx"));||
>>> ||        } catch (Throwable t) {||
>>> ||            t.printStackTrace();||
>>> ||        }||
>>> ||    }||
>>> ||}||
>>> ||=========================||
>>> | |
>>> ||JDK6 works fine, but JDK7 would crash with the second "java -cp . 
>>> -Xbootclasspath/a:foo.jar test2" command.||
>>> |
>> |I saw crash with the latest 6 update release with both test cases.
>> The crash seems to be at the same spot.
>> |
>>> |||
>>> ||So I think the correct fix is to restore the JDK6 behavior (not 
>>> sure if it's already the same with your patch, but worth checking), 
>>> and also add a new jtreg test into hotspot.||
>>> |
>> |I checked the jdk 6 code and those 3 methods which I changed look 
>> the same as jdk 8.
>> Sure, I can add a jtreg test.
>> |
>>> |||
>>> ||Thanks||
>>> ||- Ioi||
>>> ||
>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>> |
>>>> |Hi Calvin, ||
>>>> | |
>>>> ||It seems to me that this code has a general problem with 
>>>> exceptions. If exceptions can be posted then methods should be 
>>>> declared with a last parameter of TRAPS and called with a CHECK_ 
>>>> macro. The way this code is written it does not seem to expect any 
>>>> exceptions to be possible. I would check with Karen on this. ||
>>>> |
>> |I was thinking about that but that would involves a bit more changes.
>> I can give it a try.
>> |
>>>> || |
>>>> ||This addition seems unused: ||
>>>> | |
>>>> ||+   Thread* THREAD = thread; ||
>>>> |
>> |It is required for the THROW_MSG().
>> It won't be needed if the method is declared with TRAPS as the last 
>> parameter (I think).
>>
>> thanks,
>> Calvin
>> |
>>>> || |
>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing 
>>>> exceptions - don't know what the thought process was there :) ||
>>>> | |
>>>> ||David ||
>>>> | |
>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>> |
>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce 
>>>>> similar crash ||
>>>>> ||by trying to load a class from an empty jar which is in the ||
>>>>> ||bootclasspath. The following program can trigger the crash if the ||
>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>> | |
>>>>> ||public class TestForName { ||
>>>>> ||     public static void main(String[] args) { ||
>>>>> ||         try { ||
>>>>> ||             Class cls = 
>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>> ||             System.out.println("Class = " + cls.getName()); ||
>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>> ||             cnfe.printStackTrace(); ||
>>>>> ||         } ||
>>>>> ||     } ||
>>>>> ||} ||
>>>>> | |
>>>>> ||The fix also changes the assert() in 
>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>> ||to a NULL check. Otherwise, the assert() will fail under the 
>>>>> above test ||
>>>>> ||scenario. ||
>>>>> | |
>>>>> ||With the fix, the following ClassNotFoundException will be thrown ||
>>>>> ||instead of a crash: ||
>>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>>> ||         at 
>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>> ||         at 
>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>> ||         at java.security.AccessController.doPrivileged(Native 
>>>>> Method) ||
>>>>> ||         at 
>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>> ||         at 
>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>> | |
>>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>> | |
>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>> | |
>>>>> ||Tests: ||
>>>>> ||     jprt, vm.quick.testlist ||
>>>>> | |
>>>>> ||thanks, ||
>>>>> ||Calvin ||
>>>>> | |
>>>>> | |
>>>>> |
>>> |
>>> | 
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130808/4317436b/attachment-0001.html 

From john.coomes at oracle.com  Thu Aug  8 11:45:18 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 18:45:18 +0000
Subject: hg: hsx/hotspot-emb: Added tag jdk8-b102 for changeset 5eb3c1dc348f
Message-ID: <20130808184518.4F5AE48701@hg.openjdk.java.net>

Changeset: b7e64be81c8a
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/b7e64be81c8a

Added tag jdk8-b102 for changeset 5eb3c1dc348f

! .hgtags


From john.coomes at oracle.com  Thu Aug  8 11:45:22 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 18:45:22 +0000
Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b102 for changeset
	528c7e76eaee
Message-ID: <20130808184526.05A4C48702@hg.openjdk.java.net>

Changeset: f8ed09af1df6
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/f8ed09af1df6

Added tag jdk8-b102 for changeset 528c7e76eaee

! .hgtags


From john.coomes at oracle.com  Thu Aug  8 11:45:30 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 18:45:30 +0000
Subject: hg: hsx/hotspot-emb/jaxp: 4 new changesets
Message-ID: <20130808184546.D27F248703@hg.openjdk.java.net>

Changeset: 251ca1e2ccd3
Author:    joehw
Date:      2013-07-25 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/251ca1e2ccd3

8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)
Reviewed-by: chegar, lancea, dfuchs

! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java

Changeset: 467e1948612d
Author:    lana
Date:      2013-07-26 14:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/467e1948612d

Merge


Changeset: 7cffafa606e9
Author:    lana
Date:      2013-08-06 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/7cffafa606e9

Merge


Changeset: b1ceab582fc6
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/b1ceab582fc6

Added tag jdk8-b102 for changeset 7cffafa606e9

! .hgtags


From john.coomes at oracle.com  Thu Aug  8 11:45:53 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 18:45:53 +0000
Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b102 for changeset
	988a5f2ac559
Message-ID: <20130808184601.3C57948704@hg.openjdk.java.net>

Changeset: 6cdc6ed98780
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/6cdc6ed98780

Added tag jdk8-b102 for changeset 988a5f2ac559

! .hgtags


From coleen.phillimore at oracle.com  Thu Aug  8 11:43:28 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 08 Aug 2013 14:43:28 -0400
Subject: Request for review: 7073961 [TESTBUG]
	closed/runtime/4845371/DBB.java failed on solaris 10 x64
In-Reply-To: <00da01ce9467$1e29eed0$5a7dcc70$@oracle.com>
References: <51FAAE26.5030306@oracle.com>
	<00da01ce9467$1e29eed0$5a7dcc70$@oracle.com>
Message-ID: <5203E6D0.6030403@oracle.com>


Harold, This looks good.

Coleen

On 08/08/2013 02:43 PM, Christian Tornqvist wrote:
> Change looks good, thanks for fixing this :)
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of harold seigel
> Sent: den 1 augusti 2013 14:51
> To: hotspot-runtime-dev at openjdk.java.net
> Subject: Request for review: 7073961 [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 x64
>
> Hi,
>
> Please review this small change to help fix bug 7073961.  This change adds a method that enables tests to distinguish between Solaris on Sparc and Solaris on X86.
>
> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_7073961/
> <http://cr.openjdk.java.net/%7Ehseigel/bug_7073961/>
>
> Bug link at: http://bugs.sun.com/view_bug.do?bug_id=7073961
>
> JBB Bug at: https://jbs.oracle.com/bugs/browse/JDK-7073961
>
> Thanks!  Harold
>


From ioi.lam at oracle.com  Thu Aug  8 11:52:07 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 08 Aug 2013 11:52:07 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5203DEB1.9080808@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
Message-ID: <5203E8D7.107@oracle.com>

|Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which apparently 
works differently
(better?) than the official JDK6 build. Maybe Redhat fixed this in their 
own repo??||
||
|
|==OEL6================================================
||
||sc11136754 ~$ uname -a||
||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6 
20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
||sc11136754 ~$ type java||
||java is hashed (/usr/bin/java)||
||sc11136754 ~$ java -version||
||java version "1.6.0_22"||
||OpenJDK Runtime Environment (IcedTea6 1.10.4) 
(rhel-1.41.1.10.4.el6-x86_64)||
||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar test2||
||Error occurred during initialization of VM||
||java/lang/ClassNotFoundException: error in opening JAR file foo.jar||
||
==OFFICIAL============================================
||
sc11136754 ~$ /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java 
-showversion -cp . -Xbootclasspath/a:foo.jar test2
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (exceptions.cpp:367), pid=25167, tid=140510319580928
#  Error: ExceptionMark destructor expects no pending exceptions
#
# JRE version: 6.0_22-b04
# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode 
linux-amd64 )
# An error report file with more information is saved as:
# /home/iklam/hs_err_pid25167.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
|
|======================================================
||
||- Ioi|

On 08/08/2013 11:08 AM, Calvin Cheung wrote:
> Hi Ioi, David,
>
> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>> |JDK6 seems to handle this better. I have written a simple 
>> stand-alone test case that doesn't require truncating JAR files in 
>> the JDK:||
>> ||
>> ||=========================||
>> ||/*||
>> ||javac test2.java||
>> ||rm -f foo.jar||
>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>> ||touch foo.jar||
>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>> ||*/||
>> ||
>> ||public class test2 {||
>> ||    public static void main(String args[]) {||
>> ||        try {||
>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>> ||System.out.println(Class.forName("xxx"));||
>> ||        } catch (Throwable t) {||
>> ||            t.printStackTrace();||
>> ||        }||
>> ||    }||
>> ||}||
>> ||=========================||
>> | |
>> ||JDK6 works fine, but JDK7 would crash with the second "java -cp . 
>> -Xbootclasspath/a:foo.jar test2" command.||
>> |
> |I saw crash with the latest 6 update release with both test cases.
> The crash seems to be at the same spot.
> |
>> |||
>> ||So I think the correct fix is to restore the JDK6 behavior (not 
>> sure if it's already the same with your patch, but worth checking), 
>> and also add a new jtreg test into hotspot.||
>> |
> |I checked the jdk 6 code and those 3 methods which I changed look the 
> same as jdk 8.
> Sure, I can add a jtreg test.
> |
>> |||
>> ||Thanks||
>> ||- Ioi||
>> ||
>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>> |
>>> |Hi Calvin, ||
>>> | |
>>> ||It seems to me that this code has a general problem with 
>>> exceptions. If exceptions can be posted then methods should be 
>>> declared with a last parameter of TRAPS and called with a CHECK_ 
>>> macro. The way this code is written it does not seem to expect any 
>>> exceptions to be possible. I would check with Karen on this. ||
>>> |
> |I was thinking about that but that would involves a bit more changes.
> I can give it a try.
> |
>>> || |
>>> ||This addition seems unused: ||
>>> | |
>>> ||+   Thread* THREAD = thread; ||
>>> |
> |It is required for the THROW_MSG().
> It won't be needed if the method is declared with TRAPS as the last 
> parameter (I think).
>
> thanks,
> Calvin
> |
>>> || |
>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing 
>>> exceptions - don't know what the thought process was there :) ||
>>> | |
>>> ||David ||
>>> | |
>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>> |
>>>> |Please review this small fix for fixing a fatal error in ||
>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>> ||ClassLoader::create_class_path_entry(). I could reproduce similar 
>>>> crash ||
>>>> ||by trying to load a class from an empty jar which is in the ||
>>>> ||bootclasspath. The following program can trigger the crash if the ||
>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>> | |
>>>> ||public class TestForName { ||
>>>> ||     public static void main(String[] args) { ||
>>>> ||         try { ||
>>>> ||             Class cls = 
>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>> ||             System.out.println("Class = " + cls.getName()); ||
>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>> ||             cnfe.printStackTrace(); ||
>>>> ||         } ||
>>>> ||     } ||
>>>> ||} ||
>>>> | |
>>>> ||The fix also changes the assert() in 
>>>> LazyClassPathEntry::resolve_entry() ||
>>>> ||to a NULL check. Otherwise, the assert() will fail under the 
>>>> above test ||
>>>> ||scenario. ||
>>>> | |
>>>> ||With the fix, the following ClassNotFoundException will be thrown ||
>>>> ||instead of a crash: ||
>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>> ||         at java.security.AccessController.doPrivileged(Native 
>>>> Method) ||
>>>> ||         at 
>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>> ||         at 
>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>> | |
>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>> | |
>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>> | |
>>>> ||Tests: ||
>>>> ||     jprt, vm.quick.testlist ||
>>>> | |
>>>> ||thanks, ||
>>>> ||Calvin ||
>>>> | |
>>>> | |
>>>> |
>> |
>> | 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130808/571869e7/attachment-0001.html 

From john.coomes at oracle.com  Thu Aug  8 12:19:09 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 19:19:09 +0000
Subject: hg: hsx/hotspot-emb/langtools: 17 new changesets
Message-ID: <20130808192017.DBED04870A@hg.openjdk.java.net>

Changeset: 80e75aa6a707
Author:    jjg
Date:      2013-07-17 18:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/80e75aa6a707

8014636: TestLiteralCodeInPre fails on windows
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java
! test/com/sun/javadoc/testLeadingSpaces/LeadingSpaces.java
! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java
! test/com/sun/javadoc/testLiteralCodeInPre/TestLiteralCodeInPre.java
! test/com/sun/javadoc/testRelativeLinks/TestRelativeLinks.java

Changeset: 1e533c1bfb01
Author:    jjg
Date:      2013-07-17 19:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/1e533c1bfb01

8020313: doclint doesn't reset HTML anchors correctly
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/AnchorTest2.java
+ test/tools/doclint/AnchorTest2.out
+ test/tools/doclint/AnchorTest2a.java

Changeset: 1476d54fdc61
Author:    jjg
Date:      2013-07-17 19:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/1476d54fdc61

8020664: doclint gives incorrect warnings on normal package statements
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
! test/tools/doclint/BadPackageCommentTest.out
! test/tools/doclint/DocLintTester.java
+ test/tools/doclint/packageTests/bad/Test.java
+ test/tools/doclint/packageTests/bad/Test.out
+ test/tools/doclint/packageTests/bad/package-info.java
+ test/tools/doclint/packageTests/bad/package-info.out
+ test/tools/doclint/packageTests/good/Test.java
+ test/tools/doclint/packageTests/good/package-info.java

Changeset: 0a9f5cbe37d9
Author:    ksrini
Date:      2013-07-19 07:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/0a9f5cbe37d9

8017216: javac doesn't fill in end position for some errors of type not found
8019421: Javac doesn't fill in end position for some annotation related errors
8019422: Javac doesn't fill in end position for uninitialized variable errors
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/EndPosTable.java
+ test/tools/javac/diags/examples/VarNotIntializedInDefaultConstructor.java
+ test/tools/javac/positions/TreeEndPosTest.java

Changeset: 129751018061
Author:    jjg
Date:      2013-07-23 16:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/129751018061

8021215: javac gives incorrect doclint warnings on normal package statements
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/DocLint.java
! test/tools/doclint/packageTests/bad/Test.java
+ test/tools/doclint/packageTests/bad/Test.javac.out
! test/tools/doclint/packageTests/bad/Test.out
! test/tools/doclint/packageTests/bad/package-info.java
+ test/tools/doclint/packageTests/bad/package-info.javac.out
! test/tools/doclint/packageTests/bad/package-info.out
! test/tools/doclint/packageTests/good/Test.java
! test/tools/doclint/packageTests/good/package-info.java

Changeset: 558fe98d1ac0
Author:    emc
Date:      2013-07-23 20:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/558fe98d1ac0

8016880: 42 tests in annot102* fail with compile-time errors.
Summary: Fixes error in type equality when bounds of type variables have annotations.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/annotations/typeAnnotations/ErasureTest.java

Changeset: 2fbe77c38802
Author:    jjg
Date:      2013-07-24 17:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/2fbe77c38802

8020556: doclint does not check type variables for @throws
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/DocTrees.java
! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/comp/Env.java
! test/tools/doclint/ReferenceTest.java

Changeset: a218f7befd55
Author:    jfranck
Date:      2013-07-25 11:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/a218f7befd55

8007961: javax.lang.model tests for repeating annotations fail in getAnnotationsByType
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java
! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java
! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java
! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java
! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java
! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java
+ test/tools/javac/processing/model/inheritedByType/EnsureOrder.java

Changeset: 3155e77d2676
Author:    mcimadamore
Date:      2013-07-25 14:47 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/3155e77d2676

8020804: javac crashes when speculative attribution infers intersection type with array component
Summary: Assertion is causing javac to crash because of lack of support for arrays in intersection types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/lambda/8020804/T8020804.java

Changeset: b02f28bf7f1c
Author:    mcimadamore
Date:      2013-07-25 14:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/b02f28bf7f1c

8016081: field initialized with lambda in annotation types doesn't compile
Summary: check for annotation attributes should skip over synthetic methods
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/lambda/8016081/T8016081.java

Changeset: dae52d74c1fc
Author:    mcimadamore
Date:      2013-07-25 14:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/dae52d74c1fc

8020843: javac crashes on accessibility check with method reference with typevar receiver
Summary: method reference overload check doesn't walk through type-variable receivers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/ReportAccessFragment.java
+ test/tools/javac/lambda/8020843/T8020843a.java
+ test/tools/javac/lambda/8020843/T8020843a.out
+ test/tools/javac/lambda/8020843/T8020843b.java
+ test/tools/javac/lambda/8020843/T8020843b.out
! test/tools/javac/lambda/MethodReference28.out

Changeset: 37048aa3ac19
Author:    lana
Date:      2013-07-26 14:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/37048aa3ac19

Merge


Changeset: 8c4b2987edac
Author:    jlahoda
Date:      2013-07-28 10:17 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/8c4b2987edac

8020689: Missing LineNumberTable entries in compiled class files
Reviewed-by: ksrini, mcimadamore

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/jvm/T8020689.java

Changeset: cd9e8cea1b3c
Author:    jlahoda
Date:      2013-07-28 10:17 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/cd9e8cea1b3c

8021338: Diamond finder may mark a required type argument as unnecessary
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! test/tools/javac/generics/diamond/6939780/T6939780.java

Changeset: 7696282873f6
Author:    vromero
Date:      2013-07-31 10:52 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/7696282873f6

8013179: assertion failure in javac when compiling with -source 1.6 -target 1.6
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/MethodInvokedWithWrongNumberOfArgs.java

Changeset: 453a305e1165
Author:    lana
Date:      2013-08-06 10:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/453a305e1165

Merge


Changeset: 6718df4cd616
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/6718df4cd616

Added tag jdk8-b102 for changeset 453a305e1165

! .hgtags


From john.coomes at oracle.com  Thu Aug  8 12:20:30 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 19:20:30 +0000
Subject: hg: hsx/hotspot-emb/nashorn: 29 new changesets
Message-ID: <20130808192059.CA31A4870B@hg.openjdk.java.net>

Changeset: e1d19f9fd5a9
Author:    jlaskey
Date:      2013-07-16 17:40 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/e1d19f9fd5a9

8017585: Exclude two failing tests from Nashorn CC run
Reviewed-by: jlaskey, sundar, attila
Contributed-by: konstantin.shefov at oracle.com

+ exclude/exclude_list.txt
+ exclude/exclude_list_cc.txt
! make/build.xml

Changeset: 71cfe4e66bcb
Author:    jlaskey
Date:      2013-07-17 11:53 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/71cfe4e66bcb

8020596: Initialization of white space strings in scanner should be done with \u strings
Reviewed-by: attila, hannesw
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/parser/Lexer.java

Changeset: 3d6f6b8d8bc8
Author:    hannesw
Date:      2013-07-17 18:20 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/3d6f6b8d8bc8

8020356: ClassCastException Undefined->Scope on spiltter class generated for a large switch statement
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/Label.java
! src/jdk/nashorn/internal/codegen/Splitter.java
! src/jdk/nashorn/internal/codegen/WeighNodes.java
! src/jdk/nashorn/internal/ir/Block.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/LexicalContext.java
+ test/script/basic/JDK-8020356.js
+ test/script/basic/JDK-8020356.js.EXPECTED

Changeset: e3307f1a30e5
Author:    sundar
Date:      2013-07-18 18:08 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/e3307f1a30e5

8020731: Revisit checkPermission calls in Context class
Reviewed-by: attila, hannesw

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
- src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java

Changeset: 624f8be5c3fe
Author:    attila
Date:      2013-07-18 16:22 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/624f8be5c3fe

8020809: Java adapter should not allow overriding of caller sensitive methods
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
+ test/script/trusted/JDK-8020809.js
+ test/script/trusted/JDK-8020809.js.EXPECTED

Changeset: 4b06441b7624
Author:    attila
Date:      2013-07-18 16:47 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/4b06441b7624

8020820: Limit access to static members of reflective classes
Reviewed-by: jlaskey, sundar

! make/build.xml
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! test/script/basic/JDK-8010946-2.js
! test/script/basic/JDK-8010946-2.js.EXPECTED
! test/script/basic/NASHORN-473.js
+ test/script/basic/classloader.js
+ test/script/basic/classloader.js.EXPECTED
! test/script/basic/javaarray.js
! test/script/sandbox/classloader.js.EXPECTED
! test/script/sandbox/reflection.js
! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java

Changeset: 0cfa27ed82fe
Author:    sundar
Date:      2013-07-23 18:17 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/0cfa27ed82fe

8021122: Not all callables are handled for toString and other function valued properties
Reviewed-by: attila, hannesw, jlaskey

! src/jdk/nashorn/internal/ir/debug/ASTWriter.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeDate.java
! src/jdk/nashorn/internal/objects/NativeJSON.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
+ test/script/basic/JDK-8021122.js
+ test/script/basic/JDK-8021122.js.EXPECTED

Changeset: e86b297d26aa
Author:    jlaskey
Date:      2013-07-23 12:00 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/e86b297d26aa

8021130: Comments need to be tokens
Reviewed-by: lagergren, attila
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/parser/AbstractParser.java
! src/jdk/nashorn/internal/parser/Lexer.java
! src/jdk/nashorn/internal/parser/TokenType.java

Changeset: ccbea9172aa5
Author:    sundar
Date:      2013-07-23 21:45 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/ccbea9172aa5

8021164: REGRESSION: test262 failures after JDK-8021122
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java

Changeset: 4cb1780bc385
Author:    sundar
Date:      2013-07-23 21:51 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/4cb1780bc385

Merge

- src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java

Changeset: 8b97fe2b7c98
Author:    attila
Date:      2013-07-23 18:28 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/8b97fe2b7c98

8021129: Use public lookup again
Reviewed-by: lagergren, sundar

! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk/internal/dynalink/beans/FacetIntrospector.java
- src/jdk/internal/dynalink/beans/SafeUnreflector.java
- src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java
- src/jdk/internal/dynalink/beans/SandboxClassLoader.java
- src/jdk/internal/dynalink/beans/sandbox/Unreflector.java
+ test/script/trusted/JDK-8021129.js
+ test/script/trusted/JDK-8021129.js.EXPECTED
+ test/src/jdk/nashorn/internal/test/models/InternalRunnable.java
+ test/src/jdk/nashorn/internal/test/models/RestrictedRunnable.java
+ test/src/jdk/nashorn/test/models/InternalRunnableSuperclass.java

Changeset: a58a07a00122
Author:    attila
Date:      2013-07-24 11:13 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/a58a07a00122

8021189: Prevent access to constructors of restricted classes
Reviewed-by: lagergren, sundar

! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk/internal/dynalink/beans/FacetIntrospector.java
! src/jdk/internal/dynalink/beans/StaticClassLinker.java
! test/script/trusted/JDK-8006529.js
! test/script/trusted/JDK-8021129.js
+ test/script/trusted/JDK-8021189.js
+ test/script/trusted/JDK-8021189.js.EXPECTED

Changeset: e4efb3ce97b2
Author:    attila
Date:      2013-07-24 12:48 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/e4efb3ce97b2

8021246: Fix regression for 8021189
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! test/script/trusted/JDK-8006529.js

Changeset: 2a25917777f7
Author:    hannesw
Date:      2013-07-24 13:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/2a25917777f7

8020718: RETURN symbol has wrong type in split functions
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk/nashorn/internal/codegen/SplitMethodEmitter.java
! src/jdk/nashorn/internal/ir/Block.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/Symbol.java

Changeset: 573cc6eb66ae
Author:    jlaskey
Date:      2013-07-24 08:25 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/573cc6eb66ae

Merge

- src/jdk/internal/dynalink/beans/SafeUnreflector.java
- src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java
- src/jdk/internal/dynalink/beans/SandboxClassLoader.java
- src/jdk/internal/dynalink/beans/sandbox/Unreflector.java

Changeset: dc54df348a58
Author:    sundar
Date:      2013-07-24 20:28 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/dc54df348a58

8021262: Make nashorn access checks consistent with underlying dynalink
Reviewed-by: jlaskey, lagergren, attila

! make/code_coverage.xml
! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java
! src/jdk/nashorn/internal/objects/NativeDate.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/NashornLoader.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/Source.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java
! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java
! test/script/sandbox/nashorninternals.js
! test/script/trusted/JDK-8006529.js
! test/script/trusted/JDK-8021129.js
! test/script/trusted/JDK-8021189.js
! test/script/trusted/JDK-8021189.js.EXPECTED
! test/src/jdk/nashorn/test/models/InternalRunnableSuperclass.java

Changeset: d203d68f6624
Author:    sundar
Date:      2013-07-24 21:01 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/d203d68f6624

8021294: --verify-code option results in AnalyzerException
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/runtime/Context.java

Changeset: 5c035c4ccc61
Author:    sundar
Date:      2013-07-25 14:05 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/5c035c4ccc61

8021252: invokeMethod throws NoSuchMethodException when script object is from different script context
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: f74faac51bfb
Author:    hannesw
Date:      2013-07-25 11:56 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/f74faac51bfb

8021244: Inconsistent stackmap with splitter threshold set very low
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/ir/Block.java

Changeset: f22ca0f9b6ee
Author:    sundar
Date:      2013-07-25 20:10 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/f22ca0f9b6ee

8021361: ClassCastException:.ScriptObjectMirror -> ScriptObject when getInterface called on object from different ScriptContext
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
+ src/jdk/nashorn/api/scripting/resources/Messages.properties
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: d55856f82352
Author:    lana
Date:      2013-07-26 14:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/d55856f82352

Merge


Changeset: f6588f168d79
Author:    hannesw
Date:      2013-07-26 13:50 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/f6588f168d79

8020719: Run tests with reduced splitter threshold
Reviewed-by: lagergren, sundar, jlaskey

! make/build.xml
! make/project.properties
+ test/script/basic/NASHORN-592-dual.js
+ test/script/basic/NASHORN-592-dual.js.EXPECTED
+ test/script/basic/compile-octane-splitter.js
+ test/script/basic/compile-octane-splitter.js.EXPECTED
+ test/script/basic/splitter.js
+ test/script/basic/splitter.js.EXPECTED
- test/script/representations/NASHORN-592a.js
! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/TestConfig.java
! test/src/jdk/nashorn/internal/test/framework/TestFinder.java

Changeset: 17a947418e65
Author:    jlaskey
Date:      2013-07-26 09:17 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/17a947418e65

8021321: Two runsunspider tests fail after updating sunspider to 1.0
Reviewed-by: jlaskey, sundar
Contributed-by: michael.horowitz at oracle.com

! test/script/basic/runsunspider.js

Changeset: fbd21b00197b
Author:    sundar
Date:      2013-07-26 20:10 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/fbd21b00197b

8021571: @fork tests should use VM options passed from project.properties
Reviewed-by: lagergren, hannesw, jlaskey

! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java
! make/project.properties
! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java
! src/jdk/nashorn/internal/objects/PrototypeObject.java
! src/jdk/nashorn/internal/runtime/AccessorProperty.java
! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk/nashorn/internal/runtime/Property.java
! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java
! src/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk/nashorn/internal/runtime/linker/AdaptationException.java
! src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java
! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java
! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java
! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java
! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/TestConfig.java

Changeset: 5fc6b7f11289
Author:    sundar
Date:      2013-07-29 10:28 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/5fc6b7f11289

Merge

- test/script/representations/NASHORN-592a.js

Changeset: 0532397d0732
Author:    sundar
Date:      2013-07-29 18:07 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/0532397d0732

8012792: print function defined in engine.js does not handle multiple arguments
Reviewed-by: hannesw

! src/jdk/nashorn/api/scripting/resources/engine.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: 7d5d24bdb671
Author:    sundar
Date:      2013-07-29 21:56 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/7d5d24bdb671

Merge


Changeset: e966ff0a3ffe
Author:    lana
Date:      2013-08-06 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/e966ff0a3ffe

Merge


Changeset: 795cff5c1b5c
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/795cff5c1b5c

Added tag jdk8-b102 for changeset e966ff0a3ffe

! .hgtags


From harold.seigel at oracle.com  Thu Aug  8 12:23:16 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 08 Aug 2013 15:23:16 -0400
Subject: Request for Review 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh
	fails on 64-bit solaris
Message-ID: <5203F024.9040006@oracle.com>

Hi,

Please review this change to fix bug 7121403.  The test was rewritten in 
Java and modified to properly determine when it is running on 64-bit 
Solaris.

The fix was tested by running the new test on 32-bit Linux, Solaris 
Sparc, Solaris X86, and 64-bit Linux.

webrev: http://cr.openjdk.java.net/~hseigel/bug_7121403/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_7121403/>

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

JBS bug: https://jbs.oracle.com/bugs/browse/JDK-7121403

Thanks! Harold

From yumin.qi at oracle.com  Thu Aug  8 12:48:41 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 08 Aug 2013 12:48:41 -0700
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
In-Reply-To: <52017AC9.9040809@oracle.com>
References: <52017AC9.9040809@oracle.com>
Message-ID: <5203F619.3020308@oracle.com>

Hi,

   Thanks for the comments from David and Ioi  ---  I misunderstand the 
problem, the problem is in shell script in which

   if [...]

   will change result $? since it always be the result of last script 
cmd.  Now fix by recording the result in a variable.

  http://cr.openjdk.java.net/~minqi/8019583/webrev1

Thanks
Yumin


On 8/6/2013 3:38 PM, Yumin Qi wrote:
> Please review:
>
> http://cr.openjdk.java.net/~minqi/8019583/webrev0/ 
> <http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>
>
> Summary: The test will always pass since TestMT.java will always 
> return value 0 to shell. Fix by recording failure value and exit with it.
>
> Thanks
> Yumin


From john.coomes at oracle.com  Thu Aug  8 13:18:01 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 20:18:01 +0000
Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b102 for changeset
	528c7e76eaee
Message-ID: <20130808201804.1AC454871D@hg.openjdk.java.net>

Changeset: f8ed09af1df6
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/f8ed09af1df6

Added tag jdk8-b102 for changeset 528c7e76eaee

! .hgtags


From john.coomes at oracle.com  Thu Aug  8 13:17:52 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 20:17:52 +0000
Subject: hg: hsx/hotspot-rt: Added tag jdk8-b102 for changeset 5eb3c1dc348f
Message-ID: <20130808201753.28BF34871C@hg.openjdk.java.net>

Changeset: b7e64be81c8a
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/b7e64be81c8a

Added tag jdk8-b102 for changeset 5eb3c1dc348f

! .hgtags


From john.coomes at oracle.com  Thu Aug  8 13:18:42 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 20:18:42 +0000
Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b102 for changeset
	988a5f2ac559
Message-ID: <20130808201851.D019E4871F@hg.openjdk.java.net>

Changeset: 6cdc6ed98780
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/6cdc6ed98780

Added tag jdk8-b102 for changeset 988a5f2ac559

! .hgtags


From john.coomes at oracle.com  Thu Aug  8 13:18:12 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 20:18:12 +0000
Subject: hg: hsx/hotspot-rt/jaxp: 4 new changesets
Message-ID: <20130808201834.9F5E84871E@hg.openjdk.java.net>

Changeset: 251ca1e2ccd3
Author:    joehw
Date:      2013-07-25 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/251ca1e2ccd3

8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)
Reviewed-by: chegar, lancea, dfuchs

! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java

Changeset: 467e1948612d
Author:    lana
Date:      2013-07-26 14:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/467e1948612d

Merge


Changeset: 7cffafa606e9
Author:    lana
Date:      2013-08-06 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/7cffafa606e9

Merge


Changeset: b1ceab582fc6
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/b1ceab582fc6

Added tag jdk8-b102 for changeset 7cffafa606e9

! .hgtags


From daniel.daugherty at oracle.com  Thu Aug  8 13:26:50 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Thu, 08 Aug 2013 20:26:50 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8016601: Unable to build hsx24 on Windows
	using project creator and Visual Studio
Message-ID: <20130808202657.4FFBC48722@hg.openjdk.java.net>

Changeset: 31f3b1e1c5e5
Author:    dcubed
Date:      2013-08-08 09:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/31f3b1e1c5e5

8016601: Unable to build hsx24 on Windows using project creator and Visual Studio
Summary: ProjectCreator tool is modified to support two new options: '-relativeAltSrcInclude' and '-altRelativeInclude' which prevents IDE linker errors. Also fixed some cmd line build linker warnings. Misc cleanups.
Reviewed-by: rdurbin, coleenp

! make/windows/create.bat
! make/windows/create_obj_files.sh
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/trace.make
! make/windows/makefiles/vm.make
! src/share/tools/ProjectCreator/BuildConfig.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java


From ioi.lam at oracle.com  Thu Aug  8 13:38:12 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 08 Aug 2013 13:38:12 -0700
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
In-Reply-To: <5203F619.3020308@oracle.com>
References: <52017AC9.9040809@oracle.com> <5203F619.3020308@oracle.com>
Message-ID: <520401B4.6020904@oracle.com>

Yumin,

The patch looks good (not a Reviewer).

Thanks
- Ioi

On 08/08/2013 12:48 PM, Yumin Qi wrote:
> Hi,
>
>   Thanks for the comments from David and Ioi  ---  I misunderstand the 
> problem, the problem is in shell script in which
>
>   if [...]
>
>   will change result $? since it always be the result of last script 
> cmd.  Now fix by recording the result in a variable.
>
>  http://cr.openjdk.java.net/~minqi/8019583/webrev1
>
> Thanks
> Yumin
>
>
> On 8/6/2013 3:38 PM, Yumin Qi wrote:
>> Please review:
>>
>> http://cr.openjdk.java.net/~minqi/8019583/webrev0/ 
>> <http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>
>>
>> Summary: The test will always pass since TestMT.java will always 
>> return value 0 to shell. Fix by recording failure value and exit with 
>> it.
>>
>> Thanks
>> Yumin
>


From john.coomes at oracle.com  Thu Aug  8 13:22:57 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 20:22:57 +0000
Subject: hg: hsx/hotspot-rt/jdk: 73 new changesets
Message-ID: <20130808204151.60BC248724@hg.openjdk.java.net>

Changeset: 2978c0a543ed
Author:    prr
Date:      2013-07-22 12:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2978c0a543ed

7196866: CTW fails on all Solaris platforms
Reviewed-by: prr, jrose, twisti, kvn

! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/java2d/x11/XRBackendNative.c

Changeset: 784589c7bc55
Author:    vadim
Date:      2013-07-24 13:38 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/784589c7bc55

8008782: NPE in TrueTypeGlyphMapper
Reviewed-by: bae, prr

! src/share/classes/sun/font/TrueTypeFont.java

Changeset: db2e3a686cf3
Author:    jchen
Date:      2013-07-24 12:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/db2e3a686cf3

8011709: [parfait] False positive: memory leak in jdk/src/share/native/sun/font/layout/CanonShaping.cpp
Reviewed-by: jgodinez, prr

! src/share/native/sun/font/layout/CanonShaping.cpp

Changeset: c2e27e7a42ae
Author:    jchen
Date:      2013-07-24 13:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c2e27e7a42ae

8005126: [parfait] #418 - #428 XRBackendNative.c Integer overflow
Reviewed-by: prr, vadim

! src/solaris/native/sun/java2d/x11/XRBackendNative.c

Changeset: 833f05116f7b
Author:    bae
Date:      2013-07-25 17:14 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/833f05116f7b

8019201: Regression: java.awt.image.ConvolveOp throws java.awt.image.ImagingOpException
Reviewed-by: prr

! src/share/native/sun/awt/medialib/awt_ImagingLib.c
+ test/sun/awt/image/ImagingLib/SamePackingTypeTest.java

Changeset: a8b9df782017
Author:    serb
Date:      2013-07-26 21:18 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a8b9df782017

7190349: [macosx] Text (Label) is incorrectly drawn with a rotated g2d
8013569: [macosx] JLabel preferred size incorrect on retina displays with non-default font size
Reviewed-by: prr

! src/macosx/classes/sun/font/CStrike.java
! src/macosx/native/sun/font/AWTStrike.h
! src/macosx/native/sun/font/AWTStrike.m
! src/macosx/native/sun/font/CGGlyphImages.m
+ test/java/awt/Graphics2D/DrawString/DrawRotatedString.java
+ test/java/awt/Graphics2D/IncorrectTextSize/IncorrectTextSize.java

Changeset: 467a0c21790b
Author:    jgodinez
Date:      2013-07-26 15:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/467a0c21790b

8020208: NullPointerException at sun.print.Win32PrintService.getMediaPrintables
Reviewed-by: jchen, prr

! src/windows/classes/sun/print/Win32PrintService.java

Changeset: 56c6f9a9653d
Author:    jgodinez
Date:      2013-07-26 15:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/56c6f9a9653d

8016343: [macosx] Print job goes to default printer regardless of chosen printer
Reviewed-by: jchen, prr

! src/share/classes/sun/print/PSPrinterJob.java
! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintJob.java
! test/javax/print/DialogMargins.java

Changeset: 1c48544c3da9
Author:    lana
Date:      2013-07-26 15:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1c48544c3da9

Merge

- src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties
- src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- test/java/util/Collections/EmptySortedSet.java

Changeset: 921338e44ba7
Author:    lana
Date:      2013-07-26 17:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/921338e44ba7

Merge


Changeset: 046025f78ea8
Author:    jgodinez
Date:      2013-07-30 13:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/046025f78ea8

8021835: Fix for 8016343 will not compile on Windows.
Reviewed-by: jchen, prr

! src/share/classes/sun/print/PSPrinterJob.java

Changeset: 7f0e569c5a66
Author:    bae
Date:      2013-07-31 13:11 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7f0e569c5a66

8020983: OutOfMemoryError caused by non garbage collected JPEGImageWriter Instances
Reviewed-by: prr, flar

! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
+ test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java

Changeset: 607ad960fe24
Author:    malenkov
Date:      2013-07-22 15:36 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/607ad960fe24

8019975: closed/javax/swing/JFileChooser/4966171/bug4966171.java throws java.io.NotSerializableException: javax.swing.plaf.basic.BasicFileChooserUI$AcceptAllFileFilter
Reviewed-by: alexsch

! src/share/classes/javax/swing/JFileChooser.java

Changeset: 3cbe376233a9
Author:    malenkov
Date:      2013-07-22 20:33 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3cbe376233a9

8015926: NPE when using SynthTreeUI's expandPath()
Reviewed-by: alexsch

! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java
+ test/javax/swing/plaf/synth/Test8015926.java

Changeset: bdad697c03aa
Author:    pchelko
Date:      2013-07-23 13:09 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bdad697c03aa

7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session)
Reviewed-by: art, anthony

! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java

Changeset: 99ee6ddab113
Author:    serb
Date:      2013-07-24 17:14 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/99ee6ddab113

8017189: [macosx] AWT program menu disabled on Mac
Reviewed-by: leonidr, anthony

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.h
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/CMenuBar.m

Changeset: 7bd6eda2d217
Author:    leonidr
Date:      2013-07-26 16:22 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7bd6eda2d217

8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working
Reviewed-by: anthony, serb

! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java
! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/CMenuItem.m

Changeset: 65c90209edbb
Author:    lana
Date:      2013-07-26 15:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/65c90209edbb

Merge

- src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties
- src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- test/java/util/Collections/EmptySortedSet.java

Changeset: 37016eaea5d2
Author:    serb
Date:      2013-07-29 16:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/37016eaea5d2

6230360: Spelling mistake in documentation for AWT: 1.4, 1.5, 1.6, 1.7
Reviewed-by: malenkov, art

! src/share/classes/java/awt/AWTException.java

Changeset: bf80c2965a84
Author:    malenkov
Date:      2013-07-29 18:48 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bf80c2965a84

8010782: clean up source files containing carriage return characters
Reviewed-by: alexsch, art

! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth.properties

Changeset: 1e482f58c747
Author:    ant
Date:      2013-07-30 16:15 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1e482f58c747

8020927: JLightweightFrame API should export layout properties change notifications
Reviewed-by: anthony

! src/share/classes/sun/swing/JLightweightFrame.java
! src/share/classes/sun/swing/LightweightContent.java

Changeset: 336a94dbecb5
Author:    malenkov
Date:      2013-07-30 17:46 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/336a94dbecb5

8015300: JComboBox text sometimes become selected, sometimes not (Windows LAF)
Reviewed-by: alexsch, serb

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java
+ test/javax/swing/JComboBox/8015300/Test8015300.java

Changeset: 726ac8f75b54
Author:    lana
Date:      2013-07-31 12:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/726ac8f75b54

Merge


Changeset: 6e10d93273d0
Author:    juh
Date:      2013-07-18 10:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6e10d93273d0

8020426: Fix doclint accessibility issues in java.io
Reviewed-by: mduigou, darcy, chegar

! src/share/classes/java/io/DataInput.java
! src/share/classes/java/io/File.java
! src/share/classes/java/io/ObjectStreamField.java
! src/share/classes/java/io/RandomAccessFile.java

Changeset: b39797bb86c0
Author:    sherman
Date:      2013-07-18 11:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b39797bb86c0

8016025: JSR 310 DateTime API Updates IV
8020418: Cleanup of -Xlint warnings in java.time
8016623: test/java/time/format/TestDateTimeTextProvider.java failing
Summary: Integration of JSR310 Date/Time API update IV
Reviewed-by: sherman
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com, chand.basha at oracle.com

! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/Month.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoDateImpl.java
! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/Era.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/chrono/package-info.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/time/format/DateTimePrintContext.java
! src/share/classes/java/time/format/Parsed.java
! src/share/classes/java/time/temporal/ChronoField.java
! src/share/classes/java/time/temporal/ChronoUnit.java
! src/share/classes/java/time/temporal/IsoFields.java
! src/share/classes/java/time/temporal/JulianFields.java
! src/share/classes/java/time/temporal/Temporal.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
! src/share/classes/java/time/temporal/TemporalField.java
! src/share/classes/java/time/temporal/TemporalUnit.java
! src/share/classes/java/time/temporal/ValueRange.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/lib/hijrah-config-umalqura.properties
! test/java/time/tck/java/time/MockSimplePeriod.java
! test/java/time/tck/java/time/TCKClock_Fixed.java
! test/java/time/tck/java/time/TCKDayOfWeek.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKMonth.java
! test/java/time/tck/java/time/TCKMonthDay.java
! test/java/time/tck/java/time/TCKOffsetDateTime.java
! test/java/time/tck/java/time/TCKOffsetTime.java
! test/java/time/tck/java/time/TCKPeriod.java
! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZoneId.java
! test/java/time/tck/java/time/TCKZonedDateTime.java
! test/java/time/tck/java/time/chrono/CopticDate.java
! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java
! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java
! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java
! test/java/time/tck/java/time/chrono/TCKChronology.java
! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java
! test/java/time/tck/java/time/chrono/TCKHijrahEra.java
! test/java/time/tck/java/time/chrono/TCKIsoChronology.java
! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java
! test/java/time/tck/java/time/chrono/TCKJapaneseEra.java
! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java
! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java
+ test/java/time/tck/java/time/format/TCKFormatStyle.java
+ test/java/time/tck/java/time/format/TCKResolverStyle.java
+ test/java/time/tck/java/time/format/TCKSignStyle.java
! test/java/time/tck/java/time/format/TCKTextStyle.java
! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java
+ test/java/time/tck/java/time/temporal/TCKChronoField.java
+ test/java/time/tck/java/time/temporal/TCKChronoUnit.java
! test/java/time/tck/java/time/temporal/TCKWeekFields.java
! test/java/time/tck/java/time/zone/TCKZoneRules.java
! test/java/time/test/java/time/MockSimplePeriod.java
! test/java/time/test/java/time/chrono/TestChronoLocalDate.java
! test/java/time/test/java/time/chrono/TestExampleCode.java
! test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java
! test/java/time/test/java/time/chrono/TestJapaneseChronology.java
! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
! test/java/time/test/java/time/format/TestDateTimeTextProvider.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/java/time/test/java/time/format/TestNumberPrinter.java
! test/java/time/test/java/time/format/TestReducedPrinter.java
! test/java/time/test/java/time/temporal/MockFieldNoValue.java
! test/java/time/test/java/time/temporal/MockFieldValue.java

Changeset: 2323b973adaa
Author:    darcy
Date:      2013-07-18 23:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2323b973adaa

8020810: Typo in javadoc for Class.toGenericString()
Reviewed-by: dholmes

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/reflect/Parameter.java

Changeset: e6aeeec33e53
Author:    uta
Date:      2013-07-19 12:53 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e6aeeec33e53

8016579: (process) IOException thrown by ProcessBuilder.start() method is incorrectly encoded
Reviewed-by: martin, dxu

! src/share/native/java/io/io_util.c
! src/windows/native/java/io/io_util_md.c
! src/windows/native/java/lang/ProcessImpl_md.c

Changeset: e013b32118af
Author:    darcy
Date:      2013-07-19 09:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e013b32118af

8020948: Fix doclint issues in misc package-info.java files
Reviewed-by: dholmes, chegar

! src/share/classes/java/nio/file/attribute/package-info.java
! src/share/classes/java/util/function/package-info.java

Changeset: 4bd04969a228
Author:    darcy
Date:      2013-07-20 11:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4bd04969a228

8020971: Fix doclint issues in java.nio.*
Reviewed-by: lancea

! src/share/classes/java/nio/channels/package-info.java
! src/share/classes/java/nio/charset/Charset.java
! src/share/classes/java/nio/charset/MalformedInputException.java
! src/share/classes/java/nio/charset/UnmappableCharacterException.java
! src/share/classes/java/nio/file/package-info.java

Changeset: dcd89e60051a
Author:    khazra
Date:      2013-07-22 15:24 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dcd89e60051a

8020498: Crash when both libnet.so and libmawt.so are loaded
Reviewed-by: chegar, dsamersoff

! src/share/native/java/net/net_util.c

Changeset: a3a2889b1049
Author:    dl
Date:      2013-07-22 15:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a3a2889b1049

8020976: Ensure consistent insertion for ConcurrentHashMap
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java

Changeset: a6cbb9808e4b
Author:    mduigou
Date:      2013-07-22 12:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a6cbb9808e4b

6799426: Adds constructor PriorityQueue(Comparator)
Reviewed-by: lancea

! src/share/classes/java/util/PriorityQueue.java

Changeset: 7716beb127d4
Author:    darcy
Date:      2013-07-22 22:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7716beb127d4

8021109: Add serialVersionUID to LambdaConversionException.java
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/LambdaConversionException.java

Changeset: 6f3b940fe9f8
Author:    igerasim
Date:      2013-07-23 18:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6f3b940fe9f8

8016838: improvement of RedefineBigClass and RetransformBigClass tests
Reviewed-by: dcubed

! test/ProblemList.txt
! test/java/lang/instrument/RedefineBigClass.sh
! test/java/lang/instrument/RedefineBigClassApp.java
! test/java/lang/instrument/RetransformBigClass.sh
! test/java/lang/instrument/RetransformBigClassApp.java

Changeset: 8156630c1ed3
Author:    mduigou
Date:      2013-07-23 13:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8156630c1ed3

8019840: Spec updates for java.util.function
Reviewed-by: mduigou, chegar
Contributed-by: brian.goetz at oracle.com

! src/share/classes/java/util/function/BiConsumer.java
! src/share/classes/java/util/function/BiFunction.java
! src/share/classes/java/util/function/BiPredicate.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/BooleanSupplier.java
! src/share/classes/java/util/function/Consumer.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java
! src/share/classes/java/util/function/DoubleConsumer.java
! src/share/classes/java/util/function/DoubleFunction.java
! src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/DoubleSupplier.java
! src/share/classes/java/util/function/DoubleToIntFunction.java
! src/share/classes/java/util/function/DoubleToLongFunction.java
! src/share/classes/java/util/function/DoubleUnaryOperator.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntBinaryOperator.java
! src/share/classes/java/util/function/IntConsumer.java
! src/share/classes/java/util/function/IntFunction.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/IntSupplier.java
! src/share/classes/java/util/function/IntToDoubleFunction.java
! src/share/classes/java/util/function/IntToLongFunction.java
! src/share/classes/java/util/function/IntUnaryOperator.java
! src/share/classes/java/util/function/LongBinaryOperator.java
! src/share/classes/java/util/function/LongConsumer.java
! src/share/classes/java/util/function/LongFunction.java
! src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/LongSupplier.java
! src/share/classes/java/util/function/LongToDoubleFunction.java
! src/share/classes/java/util/function/LongToIntFunction.java
! src/share/classes/java/util/function/LongUnaryOperator.java
! src/share/classes/java/util/function/ObjDoubleConsumer.java
! src/share/classes/java/util/function/ObjIntConsumer.java
! src/share/classes/java/util/function/ObjLongConsumer.java
! src/share/classes/java/util/function/Predicate.java
! src/share/classes/java/util/function/Supplier.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java
! src/share/classes/java/util/function/ToDoubleFunction.java
! src/share/classes/java/util/function/ToIntBiFunction.java
! src/share/classes/java/util/function/ToIntFunction.java
! src/share/classes/java/util/function/ToLongBiFunction.java
! src/share/classes/java/util/function/ToLongFunction.java
! src/share/classes/java/util/function/UnaryOperator.java
! src/share/classes/java/util/function/package-info.java

Changeset: 012996e9259f
Author:    mduigou
Date:      2013-07-23 13:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/012996e9259f

Merge


Changeset: 187a1f2613c0
Author:    sjiang
Date:      2013-07-24 15:47 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/187a1f2613c0

8016221: A unit test should not use a fix port to run a jmx connector
Reviewed-by: jbachorik, dfuchs

! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanDoubleInvocationTest.java
! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanInvocationTest.java
! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java

Changeset: f9224fb49890
Author:    juh
Date:      2013-07-24 12:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f9224fb49890

8016916: UnstructuredName should support DirectoryString
Reviewed-by: mullan

! src/share/classes/sun/security/pkcs/PKCS9Attribute.java
! src/share/classes/sun/security/tools/keytool/Main.java
+ test/sun/security/pkcs/pkcs9/UnstructuredName.java

Changeset: fd1b5adcfdf0
Author:    chegar
Date:      2013-07-24 22:52 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fd1b5adcfdf0

8021261: ProblemList.txt updates (7/2013)
Reviewed-by: alanb, mcimadamore

! test/ProblemList.txt

Changeset: a834ab2c1354
Author:    mullan
Date:      2013-07-25 10:58 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a834ab2c1354

8010748: Add PKIXRevocationChecker NO_FALLBACK option and improve SOFT_FAIL option
Reviewed-by: vinnie

! src/share/classes/java/security/cert/PKIXRevocationChecker.java
! src/share/classes/sun/security/provider/certpath/OCSP.java
! src/share/classes/sun/security/provider/certpath/OCSPResponse.java
! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! src/share/classes/sun/security/provider/certpath/ReverseState.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java
! test/java/security/cert/PKIXRevocationChecker/UnitTest.java

Changeset: 22a391706a0b
Author:    mullan
Date:      2013-07-25 11:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/22a391706a0b

Merge

- make/sun/xawt/ToBin.java
- makefiles/sun/awt/X11/ToBin.java
- src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties
- src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java
- src/share/classes/java/security/acl/package.html
- src/share/classes/java/security/cert/package.html
- src/share/classes/java/security/interfaces/package.html
- src/share/classes/java/security/package.html
- src/share/classes/java/security/spec/package.html
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- src/share/classes/sun/misc/Hashing.java
- src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java
- src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
- src/solaris/classes/sun/awt/X11/XIconInfo.java
- src/solaris/classes/sun/awt/X11/security-icon-bw16.png
- src/solaris/classes/sun/awt/X11/security-icon-bw24.png
- src/solaris/classes/sun/awt/X11/security-icon-bw32.png
- src/solaris/classes/sun/awt/X11/security-icon-bw48.png
- src/solaris/classes/sun/awt/X11/security-icon-interim16.png
- src/solaris/classes/sun/awt/X11/security-icon-interim24.png
- src/solaris/classes/sun/awt/X11/security-icon-interim32.png
- src/solaris/classes/sun/awt/X11/security-icon-interim48.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow16.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow24.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow32.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow48.png
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties
- test/java/lang/invoke/7196190/MHProxyTest.java
- test/java/util/Collections/EmptySortedSet.java
- test/java/util/Comparators/BasicTest.java
- test/sun/misc/Hashing.java
- test/sun/security/krb5/auto/ReplayCache.java

Changeset: 21120e3682ef
Author:    darcy
Date:      2013-07-25 09:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/21120e3682ef

8021408: Fix misc doclint issues in java.util and java.io
Reviewed-by: dholmes, chegar, psandoz

! src/share/classes/java/io/ObjectInputStream.java
! src/share/classes/java/io/ObjectOutputStream.java
! src/share/classes/java/util/jar/Attributes.java
! src/share/classes/java/util/jar/JarEntry.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/stream/StreamSupport.java

Changeset: 690dcbaa69b7
Author:    chegar
Date:      2013-07-25 19:37 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/690dcbaa69b7

8021417: Fix doclint issues in java.util.concurrent
Reviewed-by: chegar, lancea
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/share/classes/java/util/concurrent/ExecutorService.java
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/TimeUnit.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java

Changeset: 9cd5159fa870
Author:    chegar
Date:      2013-07-25 19:45 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9cd5159fa870

8021421: More doclint fixes in java.net
Reviewed-by: lancea, darcy

! src/share/classes/java/net/URI.java

Changeset: 662ec7782102
Author:    joehw
Date:      2013-07-25 13:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/662ec7782102

8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)
Reviewed-by: chegar, lancea, dfuchs

+ test/javax/xml/jaxp/parsers/8021148/JAXPSAXParserTest.java
+ test/javax/xml/jaxp/parsers/8021148/TestBase.java

Changeset: 1744a32d3db3
Author:    mullan
Date:      2013-07-25 20:12 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1744a32d3db3

8012288: XML DSig API allows wrong tag names and extra elements in SignedInfo
Reviewed-by: xuelei

! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java

Changeset: 4100ab44ba4f
Author:    mullan
Date:      2013-07-25 20:30 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4100ab44ba4f

Merge


Changeset: 86a827321c39
Author:    darcy
Date:      2013-07-25 20:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/86a827321c39

8021429: Fix lint warnings in java.lang.ref
Reviewed-by: lancea, mduigou, alanb

! src/share/classes/java/lang/ref/FinalReference.java
! src/share/classes/java/lang/ref/Finalizer.java
! src/share/classes/java/lang/ref/Reference.java
! src/share/classes/java/lang/ref/ReferenceQueue.java

Changeset: 6cc15a808b93
Author:    peytoia
Date:      2013-07-26 17:22 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6cc15a808b93

8021108: Clean up doclint warnings and errors in java.text package
Reviewed-by: darcy, okutsu

! src/share/classes/java/text/Annotation.java
! src/share/classes/java/text/AttributedCharacterIterator.java
! src/share/classes/java/text/Bidi.java
! src/share/classes/java/text/BreakIterator.java
! src/share/classes/java/text/ChoiceFormat.java
! src/share/classes/java/text/CollationElementIterator.java
! src/share/classes/java/text/CollationKey.java
! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/FieldPosition.java
! src/share/classes/java/text/Format.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/Normalizer.java
! src/share/classes/java/text/NumberFormat.java
! src/share/classes/java/text/ParseException.java
! src/share/classes/java/text/ParsePosition.java
! src/share/classes/java/text/RuleBasedCollator.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/text/StringCharacterIterator.java

Changeset: 952476b80fa7
Author:    jbachorik
Date:      2013-07-26 10:12 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/952476b80fa7

8020875: java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently
Reviewed-by: dfuchs, chegar

! test/java/lang/management/ThreadMXBean/ResetPeakThreadCount.java

Changeset: 7ae061cfd4be
Author:    juh
Date:      2013-07-26 14:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7ae061cfd4be

8019544: Need to run ProviderTest.java in othervm mode.
Reviewed-by: wetmore, xuelei, vinnie
Contributed-by: rajan.halade at oracle.com

! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java

Changeset: 25575c3c209d
Author:    lana
Date:      2013-07-26 14:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/25575c3c209d

Merge


Changeset: 9f9ffe6be557
Author:    lana
Date:      2013-07-26 15:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9f9ffe6be557

Merge


Changeset: f056728871f8
Author:    mduigou
Date:      2013-07-26 17:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f056728871f8

8021601: Add unit test for PriorityQueue(Comparator) constructor
Reviewed-by: darcy, alanb

! src/share/classes/java/util/PriorityQueue.java
! test/java/util/PriorityQueue/RemoveContains.java

Changeset: d4b2436892c8
Author:    bpb
Date:      2013-07-26 17:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d4b2436892c8

8014319: Faster division of large integers
Summary: Implement Burnickel-Ziegler division algorithm in BigInteger
Reviewed-by: bpb, martin
Contributed-by: Tim Buktu <tbuktu at hotmail.com>

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java

Changeset: a1c01457cf6c
Author:    bpb
Date:      2013-07-26 17:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a1c01457cf6c

8020641: Clean up some code style in recent BigInteger contributions
Summary: Some minor cleanup to adhere better to Java coding conventions.
Reviewed-by: darcy
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java

Changeset: eb1dc65162e8
Author:    darcy
Date:      2013-07-27 10:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eb1dc65162e8

8021609: Fix doclint issues in java.nio.charset
Reviewed-by: alanb

! src/share/classes/java/nio/charset/Charset-X-Coder.java.template

Changeset: 5d4a35823071
Author:    mduigou
Date:      2013-07-27 12:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5d4a35823071

8021588: Remove explicit othervm execution from jdk/test/Makefile
Reviewed-by: alanb

! test/Makefile

Changeset: 24bda55fca48
Author:    sundar
Date:      2013-07-29 21:39 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/24bda55fca48

8021773: print function as defined by jrunscript's init.js script is incompatible with nashorn's definition
Reviewed-by: hannesw, lagergren

! src/share/classes/com/sun/tools/script/shell/init.js

Changeset: e83fc6d9cf03
Author:    psandoz
Date:      2013-07-29 19:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e83fc6d9cf03

8020156: TreeMap.values().spliterator() does not report ORDERED
8020009: TreeMap.entrySet().spliterator() reports SORTED + null comparator but the elements are not Comparable
Reviewed-by: mduigou

! src/share/classes/java/util/TreeMap.java
+ test/java/util/Spliterator/SpliteratorCharacteristics.java

Changeset: c042fd498f79
Author:    ascarpino
Date:      2013-07-19 11:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c042fd498f79

8012971: PKCS11Test hiding exception failures
Reviewed-by: vinnie, valeriep

! test/ProblemList.txt
! test/sun/security/pkcs11/PKCS11Test.java
! test/sun/security/pkcs11/SecmodTest.java

Changeset: e47569593fa0
Author:    ascarpino
Date:      2013-07-29 13:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e47569593fa0

8020424: The NSS version should be detected before running crypto tests
Reviewed-by: valeriep

! test/ProblemList.txt
! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java
! test/sun/security/pkcs11/PKCS11Test.java
+ test/sun/security/pkcs11/README
! test/sun/security/pkcs11/ec/ReadCertificates.java
! test/sun/security/pkcs11/ec/TestCurves.java
! test/sun/security/pkcs11/ec/TestECDH.java
! test/sun/security/pkcs11/ec/TestECDH2.java
! test/sun/security/pkcs11/ec/TestECDSA.java
! test/sun/security/pkcs11/ec/TestECDSA2.java
! test/sun/security/pkcs11/ec/TestECGenSpec.java
! test/sun/security/pkcs11/ec/TestKeyFactory.java

Changeset: 613cc7beba64
Author:    xuelei
Date:      2013-07-29 19:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/613cc7beba64

8021841: Remove SSLEngineDeadlock.java from problem list
Reviewed-by: wetmore

! test/ProblemList.txt

Changeset: c76f89695c90
Author:    juh
Date:      2013-07-30 11:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c76f89695c90

8021833: javadoc cleanup in java.net
Summary: <code> and <tt> converted to {@code }; package.html to package-info.java
Reviewed-by: darcy, chegar

! src/share/classes/java/net/Authenticator.java
! src/share/classes/java/net/ContentHandler.java
! src/share/classes/java/net/ContentHandlerFactory.java
! src/share/classes/java/net/CookieHandler.java
! src/share/classes/java/net/CookieManager.java
! src/share/classes/java/net/CookiePolicy.java
! src/share/classes/java/net/CookieStore.java
! src/share/classes/java/net/DatagramPacket.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/DatagramSocketImpl.java
! src/share/classes/java/net/DatagramSocketImplFactory.java
! src/share/classes/java/net/FileNameMap.java
! src/share/classes/java/net/HttpCookie.java
! src/share/classes/java/net/HttpRetryException.java
! src/share/classes/java/net/HttpURLConnection.java
! src/share/classes/java/net/IDN.java
! src/share/classes/java/net/Inet4Address.java
! src/share/classes/java/net/Inet6Address.java
! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/net/InetSocketAddress.java
! src/share/classes/java/net/InterfaceAddress.java
! src/share/classes/java/net/JarURLConnection.java
! src/share/classes/java/net/MalformedURLException.java
! src/share/classes/java/net/MulticastSocket.java
! src/share/classes/java/net/NetPermission.java
! src/share/classes/java/net/NetworkInterface.java
! src/share/classes/java/net/PasswordAuthentication.java
! src/share/classes/java/net/PortUnreachableException.java
! src/share/classes/java/net/ProtocolException.java
! src/share/classes/java/net/Proxy.java
! src/share/classes/java/net/ProxySelector.java
! src/share/classes/java/net/ResponseCache.java
! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/Socket.java
! src/share/classes/java/net/SocketException.java
! src/share/classes/java/net/SocketImpl.java
! src/share/classes/java/net/SocketImplFactory.java
! src/share/classes/java/net/SocketInputStream.java
! src/share/classes/java/net/SocketOptions.java
! src/share/classes/java/net/SocketOutputStream.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/net/URI.java
! src/share/classes/java/net/URISyntaxException.java
! src/share/classes/java/net/URL.java
! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/net/URLDecoder.java
! src/share/classes/java/net/URLEncoder.java
! src/share/classes/java/net/URLStreamHandler.java
! src/share/classes/java/net/URLStreamHandlerFactory.java
! src/share/classes/java/net/UnknownHostException.java
! src/share/classes/java/net/UnknownServiceException.java
+ src/share/classes/java/net/package-info.java
- src/share/classes/java/net/package.html

Changeset: 8bc1bbd5b659
Author:    sherman
Date:      2013-07-30 14:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8bc1bbd5b659

8021767: test/java/time/tck/java/time/format/TCKFormatStyle.java failing
Summary: Correct to use fixed locale, not locale of test environment
Reviewed-by: alanb, okutsu
Contributed-by: roger.riggs at oracle.com

! test/java/time/tck/java/time/format/TCKFormatStyle.java

Changeset: 09a77a1bdbc3
Author:    henryjen
Date:      2013-07-30 15:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/09a77a1bdbc3

8020977: StringJoiner merges with itself not as expected
Reviewed-by: psandoz, chegar, mduigou, smarks

! src/share/classes/java/util/StringJoiner.java
! test/java/util/StringJoiner/MergeTest.java

Changeset: 76d88a752a03
Author:    psandoz
Date:      2013-07-30 11:32 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/76d88a752a03

8021863: Stream.concat incorrectly calculates unsized state
Reviewed-by: chegar

! src/share/classes/java/util/stream/Streams.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java

Changeset: d30f357c6050
Author:    psandoz
Date:      2013-07-30 14:03 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d30f357c6050

8021883: j.u.Random/RandomStream.java test needs more robust timeout duration
Reviewed-by: chegar

! test/java/util/Random/RandomStreamTest.java

Changeset: 5561b34f6d4c
Author:    bpb
Date:      2013-07-30 10:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5561b34f6d4c

8020539: Clean up doclint problems in java.util package, part 2
Summary: Clean up doclint errors and warnings in classes in java.util
Reviewed-by: darcy, chegar
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! src/share/classes/java/util/List.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/Random.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/java/util/StringJoiner.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/UUID.java
! src/share/classes/java/util/Vector.java

Changeset: 4bd51f6268f4
Author:    rbackman
Date:      2013-07-24 10:57 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4bd51f6268f4

8006324: [TEST_BUG] sun/invoke/util/ValueConversionsTest.java should be modified
Reviewed-by: kvn, twisti

! test/sun/invoke/util/ValueConversionsTest.java

Changeset: 0741b19835b0
Author:    lana
Date:      2013-07-31 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0741b19835b0

Merge

- src/share/classes/java/net/package.html

Changeset: 8ed8e2b4b90e
Author:    lana
Date:      2013-08-06 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8ed8e2b4b90e

Merge


Changeset: e057cddf0d6c
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e057cddf0d6c

Added tag jdk8-b102 for changeset 8ed8e2b4b90e

! .hgtags


From john.coomes at oracle.com  Thu Aug  8 13:44:31 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 20:44:31 +0000
Subject: hg: hsx/hotspot-rt/langtools: 17 new changesets
Message-ID: <20130808204528.DA19848725@hg.openjdk.java.net>

Changeset: 80e75aa6a707
Author:    jjg
Date:      2013-07-17 18:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/80e75aa6a707

8014636: TestLiteralCodeInPre fails on windows
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java
! test/com/sun/javadoc/testLeadingSpaces/LeadingSpaces.java
! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java
! test/com/sun/javadoc/testLiteralCodeInPre/TestLiteralCodeInPre.java
! test/com/sun/javadoc/testRelativeLinks/TestRelativeLinks.java

Changeset: 1e533c1bfb01
Author:    jjg
Date:      2013-07-17 19:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1e533c1bfb01

8020313: doclint doesn't reset HTML anchors correctly
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/AnchorTest2.java
+ test/tools/doclint/AnchorTest2.out
+ test/tools/doclint/AnchorTest2a.java

Changeset: 1476d54fdc61
Author:    jjg
Date:      2013-07-17 19:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1476d54fdc61

8020664: doclint gives incorrect warnings on normal package statements
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
! test/tools/doclint/BadPackageCommentTest.out
! test/tools/doclint/DocLintTester.java
+ test/tools/doclint/packageTests/bad/Test.java
+ test/tools/doclint/packageTests/bad/Test.out
+ test/tools/doclint/packageTests/bad/package-info.java
+ test/tools/doclint/packageTests/bad/package-info.out
+ test/tools/doclint/packageTests/good/Test.java
+ test/tools/doclint/packageTests/good/package-info.java

Changeset: 0a9f5cbe37d9
Author:    ksrini
Date:      2013-07-19 07:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/0a9f5cbe37d9

8017216: javac doesn't fill in end position for some errors of type not found
8019421: Javac doesn't fill in end position for some annotation related errors
8019422: Javac doesn't fill in end position for uninitialized variable errors
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/EndPosTable.java
+ test/tools/javac/diags/examples/VarNotIntializedInDefaultConstructor.java
+ test/tools/javac/positions/TreeEndPosTest.java

Changeset: 129751018061
Author:    jjg
Date:      2013-07-23 16:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/129751018061

8021215: javac gives incorrect doclint warnings on normal package statements
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/DocLint.java
! test/tools/doclint/packageTests/bad/Test.java
+ test/tools/doclint/packageTests/bad/Test.javac.out
! test/tools/doclint/packageTests/bad/Test.out
! test/tools/doclint/packageTests/bad/package-info.java
+ test/tools/doclint/packageTests/bad/package-info.javac.out
! test/tools/doclint/packageTests/bad/package-info.out
! test/tools/doclint/packageTests/good/Test.java
! test/tools/doclint/packageTests/good/package-info.java

Changeset: 558fe98d1ac0
Author:    emc
Date:      2013-07-23 20:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/558fe98d1ac0

8016880: 42 tests in annot102* fail with compile-time errors.
Summary: Fixes error in type equality when bounds of type variables have annotations.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/annotations/typeAnnotations/ErasureTest.java

Changeset: 2fbe77c38802
Author:    jjg
Date:      2013-07-24 17:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/2fbe77c38802

8020556: doclint does not check type variables for @throws
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/DocTrees.java
! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/comp/Env.java
! test/tools/doclint/ReferenceTest.java

Changeset: a218f7befd55
Author:    jfranck
Date:      2013-07-25 11:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a218f7befd55

8007961: javax.lang.model tests for repeating annotations fail in getAnnotationsByType
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java
! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java
! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java
! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java
! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java
! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java
+ test/tools/javac/processing/model/inheritedByType/EnsureOrder.java

Changeset: 3155e77d2676
Author:    mcimadamore
Date:      2013-07-25 14:47 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3155e77d2676

8020804: javac crashes when speculative attribution infers intersection type with array component
Summary: Assertion is causing javac to crash because of lack of support for arrays in intersection types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/lambda/8020804/T8020804.java

Changeset: b02f28bf7f1c
Author:    mcimadamore
Date:      2013-07-25 14:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b02f28bf7f1c

8016081: field initialized with lambda in annotation types doesn't compile
Summary: check for annotation attributes should skip over synthetic methods
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/lambda/8016081/T8016081.java

Changeset: dae52d74c1fc
Author:    mcimadamore
Date:      2013-07-25 14:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/dae52d74c1fc

8020843: javac crashes on accessibility check with method reference with typevar receiver
Summary: method reference overload check doesn't walk through type-variable receivers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/ReportAccessFragment.java
+ test/tools/javac/lambda/8020843/T8020843a.java
+ test/tools/javac/lambda/8020843/T8020843a.out
+ test/tools/javac/lambda/8020843/T8020843b.java
+ test/tools/javac/lambda/8020843/T8020843b.out
! test/tools/javac/lambda/MethodReference28.out

Changeset: 37048aa3ac19
Author:    lana
Date:      2013-07-26 14:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/37048aa3ac19

Merge


Changeset: 8c4b2987edac
Author:    jlahoda
Date:      2013-07-28 10:17 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8c4b2987edac

8020689: Missing LineNumberTable entries in compiled class files
Reviewed-by: ksrini, mcimadamore

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/jvm/T8020689.java

Changeset: cd9e8cea1b3c
Author:    jlahoda
Date:      2013-07-28 10:17 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/cd9e8cea1b3c

8021338: Diamond finder may mark a required type argument as unnecessary
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! test/tools/javac/generics/diamond/6939780/T6939780.java

Changeset: 7696282873f6
Author:    vromero
Date:      2013-07-31 10:52 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7696282873f6

8013179: assertion failure in javac when compiling with -source 1.6 -target 1.6
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/MethodInvokedWithWrongNumberOfArgs.java

Changeset: 453a305e1165
Author:    lana
Date:      2013-08-06 10:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/453a305e1165

Merge


Changeset: 6718df4cd616
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6718df4cd616

Added tag jdk8-b102 for changeset 453a305e1165

! .hgtags


From john.coomes at oracle.com  Thu Aug  8 13:45:38 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 20:45:38 +0000
Subject: hg: hsx/hotspot-rt/nashorn: 29 new changesets
Message-ID: <20130808204605.3668E48726@hg.openjdk.java.net>

Changeset: e1d19f9fd5a9
Author:    jlaskey
Date:      2013-07-16 17:40 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/e1d19f9fd5a9

8017585: Exclude two failing tests from Nashorn CC run
Reviewed-by: jlaskey, sundar, attila
Contributed-by: konstantin.shefov at oracle.com

+ exclude/exclude_list.txt
+ exclude/exclude_list_cc.txt
! make/build.xml

Changeset: 71cfe4e66bcb
Author:    jlaskey
Date:      2013-07-17 11:53 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/71cfe4e66bcb

8020596: Initialization of white space strings in scanner should be done with \u strings
Reviewed-by: attila, hannesw
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/parser/Lexer.java

Changeset: 3d6f6b8d8bc8
Author:    hannesw
Date:      2013-07-17 18:20 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/3d6f6b8d8bc8

8020356: ClassCastException Undefined->Scope on spiltter class generated for a large switch statement
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/Label.java
! src/jdk/nashorn/internal/codegen/Splitter.java
! src/jdk/nashorn/internal/codegen/WeighNodes.java
! src/jdk/nashorn/internal/ir/Block.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/LexicalContext.java
+ test/script/basic/JDK-8020356.js
+ test/script/basic/JDK-8020356.js.EXPECTED

Changeset: e3307f1a30e5
Author:    sundar
Date:      2013-07-18 18:08 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/e3307f1a30e5

8020731: Revisit checkPermission calls in Context class
Reviewed-by: attila, hannesw

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
- src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java

Changeset: 624f8be5c3fe
Author:    attila
Date:      2013-07-18 16:22 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/624f8be5c3fe

8020809: Java adapter should not allow overriding of caller sensitive methods
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
+ test/script/trusted/JDK-8020809.js
+ test/script/trusted/JDK-8020809.js.EXPECTED

Changeset: 4b06441b7624
Author:    attila
Date:      2013-07-18 16:47 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/4b06441b7624

8020820: Limit access to static members of reflective classes
Reviewed-by: jlaskey, sundar

! make/build.xml
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! test/script/basic/JDK-8010946-2.js
! test/script/basic/JDK-8010946-2.js.EXPECTED
! test/script/basic/NASHORN-473.js
+ test/script/basic/classloader.js
+ test/script/basic/classloader.js.EXPECTED
! test/script/basic/javaarray.js
! test/script/sandbox/classloader.js.EXPECTED
! test/script/sandbox/reflection.js
! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java

Changeset: 0cfa27ed82fe
Author:    sundar
Date:      2013-07-23 18:17 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/0cfa27ed82fe

8021122: Not all callables are handled for toString and other function valued properties
Reviewed-by: attila, hannesw, jlaskey

! src/jdk/nashorn/internal/ir/debug/ASTWriter.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeDate.java
! src/jdk/nashorn/internal/objects/NativeJSON.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
+ test/script/basic/JDK-8021122.js
+ test/script/basic/JDK-8021122.js.EXPECTED

Changeset: e86b297d26aa
Author:    jlaskey
Date:      2013-07-23 12:00 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/e86b297d26aa

8021130: Comments need to be tokens
Reviewed-by: lagergren, attila
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/parser/AbstractParser.java
! src/jdk/nashorn/internal/parser/Lexer.java
! src/jdk/nashorn/internal/parser/TokenType.java

Changeset: ccbea9172aa5
Author:    sundar
Date:      2013-07-23 21:45 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/ccbea9172aa5

8021164: REGRESSION: test262 failures after JDK-8021122
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java

Changeset: 4cb1780bc385
Author:    sundar
Date:      2013-07-23 21:51 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/4cb1780bc385

Merge

- src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java

Changeset: 8b97fe2b7c98
Author:    attila
Date:      2013-07-23 18:28 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/8b97fe2b7c98

8021129: Use public lookup again
Reviewed-by: lagergren, sundar

! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk/internal/dynalink/beans/FacetIntrospector.java
- src/jdk/internal/dynalink/beans/SafeUnreflector.java
- src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java
- src/jdk/internal/dynalink/beans/SandboxClassLoader.java
- src/jdk/internal/dynalink/beans/sandbox/Unreflector.java
+ test/script/trusted/JDK-8021129.js
+ test/script/trusted/JDK-8021129.js.EXPECTED
+ test/src/jdk/nashorn/internal/test/models/InternalRunnable.java
+ test/src/jdk/nashorn/internal/test/models/RestrictedRunnable.java
+ test/src/jdk/nashorn/test/models/InternalRunnableSuperclass.java

Changeset: a58a07a00122
Author:    attila
Date:      2013-07-24 11:13 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/a58a07a00122

8021189: Prevent access to constructors of restricted classes
Reviewed-by: lagergren, sundar

! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk/internal/dynalink/beans/FacetIntrospector.java
! src/jdk/internal/dynalink/beans/StaticClassLinker.java
! test/script/trusted/JDK-8006529.js
! test/script/trusted/JDK-8021129.js
+ test/script/trusted/JDK-8021189.js
+ test/script/trusted/JDK-8021189.js.EXPECTED

Changeset: e4efb3ce97b2
Author:    attila
Date:      2013-07-24 12:48 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/e4efb3ce97b2

8021246: Fix regression for 8021189
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! test/script/trusted/JDK-8006529.js

Changeset: 2a25917777f7
Author:    hannesw
Date:      2013-07-24 13:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/2a25917777f7

8020718: RETURN symbol has wrong type in split functions
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk/nashorn/internal/codegen/SplitMethodEmitter.java
! src/jdk/nashorn/internal/ir/Block.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/Symbol.java

Changeset: 573cc6eb66ae
Author:    jlaskey
Date:      2013-07-24 08:25 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/573cc6eb66ae

Merge

- src/jdk/internal/dynalink/beans/SafeUnreflector.java
- src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java
- src/jdk/internal/dynalink/beans/SandboxClassLoader.java
- src/jdk/internal/dynalink/beans/sandbox/Unreflector.java

Changeset: dc54df348a58
Author:    sundar
Date:      2013-07-24 20:28 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/dc54df348a58

8021262: Make nashorn access checks consistent with underlying dynalink
Reviewed-by: jlaskey, lagergren, attila

! make/code_coverage.xml
! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java
! src/jdk/nashorn/internal/objects/NativeDate.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/NashornLoader.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/Source.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java
! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java
! test/script/sandbox/nashorninternals.js
! test/script/trusted/JDK-8006529.js
! test/script/trusted/JDK-8021129.js
! test/script/trusted/JDK-8021189.js
! test/script/trusted/JDK-8021189.js.EXPECTED
! test/src/jdk/nashorn/test/models/InternalRunnableSuperclass.java

Changeset: d203d68f6624
Author:    sundar
Date:      2013-07-24 21:01 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/d203d68f6624

8021294: --verify-code option results in AnalyzerException
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/runtime/Context.java

Changeset: 5c035c4ccc61
Author:    sundar
Date:      2013-07-25 14:05 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/5c035c4ccc61

8021252: invokeMethod throws NoSuchMethodException when script object is from different script context
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: f74faac51bfb
Author:    hannesw
Date:      2013-07-25 11:56 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f74faac51bfb

8021244: Inconsistent stackmap with splitter threshold set very low
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/ir/Block.java

Changeset: f22ca0f9b6ee
Author:    sundar
Date:      2013-07-25 20:10 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f22ca0f9b6ee

8021361: ClassCastException:.ScriptObjectMirror -> ScriptObject when getInterface called on object from different ScriptContext
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
+ src/jdk/nashorn/api/scripting/resources/Messages.properties
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: d55856f82352
Author:    lana
Date:      2013-07-26 14:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/d55856f82352

Merge


Changeset: f6588f168d79
Author:    hannesw
Date:      2013-07-26 13:50 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f6588f168d79

8020719: Run tests with reduced splitter threshold
Reviewed-by: lagergren, sundar, jlaskey

! make/build.xml
! make/project.properties
+ test/script/basic/NASHORN-592-dual.js
+ test/script/basic/NASHORN-592-dual.js.EXPECTED
+ test/script/basic/compile-octane-splitter.js
+ test/script/basic/compile-octane-splitter.js.EXPECTED
+ test/script/basic/splitter.js
+ test/script/basic/splitter.js.EXPECTED
- test/script/representations/NASHORN-592a.js
! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/TestConfig.java
! test/src/jdk/nashorn/internal/test/framework/TestFinder.java

Changeset: 17a947418e65
Author:    jlaskey
Date:      2013-07-26 09:17 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/17a947418e65

8021321: Two runsunspider tests fail after updating sunspider to 1.0
Reviewed-by: jlaskey, sundar
Contributed-by: michael.horowitz at oracle.com

! test/script/basic/runsunspider.js

Changeset: fbd21b00197b
Author:    sundar
Date:      2013-07-26 20:10 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/fbd21b00197b

8021571: @fork tests should use VM options passed from project.properties
Reviewed-by: lagergren, hannesw, jlaskey

! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java
! make/project.properties
! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java
! src/jdk/nashorn/internal/objects/PrototypeObject.java
! src/jdk/nashorn/internal/runtime/AccessorProperty.java
! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk/nashorn/internal/runtime/Property.java
! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java
! src/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk/nashorn/internal/runtime/linker/AdaptationException.java
! src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java
! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java
! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java
! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java
! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java
! test/src/jdk/nashorn/internal/test/framework/TestConfig.java

Changeset: 5fc6b7f11289
Author:    sundar
Date:      2013-07-29 10:28 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/5fc6b7f11289

Merge

- test/script/representations/NASHORN-592a.js

Changeset: 0532397d0732
Author:    sundar
Date:      2013-07-29 18:07 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/0532397d0732

8012792: print function defined in engine.js does not handle multiple arguments
Reviewed-by: hannesw

! src/jdk/nashorn/api/scripting/resources/engine.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: 7d5d24bdb671
Author:    sundar
Date:      2013-07-29 21:56 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/7d5d24bdb671

Merge


Changeset: e966ff0a3ffe
Author:    lana
Date:      2013-08-06 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/e966ff0a3ffe

Merge


Changeset: 795cff5c1b5c
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/795cff5c1b5c

Added tag jdk8-b102 for changeset e966ff0a3ffe

! .hgtags


From coleen.phillimore at oracle.com  Thu Aug  8 13:56:01 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 08 Aug 2013 16:56:01 -0400
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
In-Reply-To: <5203F619.3020308@oracle.com>
References: <52017AC9.9040809@oracle.com> <5203F619.3020308@oracle.com>
Message-ID: <520405E1.20503@oracle.com>


Hi Yumin,
With the test_env.sh script a lot of things in the case statement are 
now set by that script, so you don't need lines 56-58.

Also lines 90 and 91 don't match - it doesn't echo what it does.

Otherwise, it looks fine.  I don't need to see the code again after you 
fix these (but verify the changes don't break anything!)

Thanks,
Coleen

On 08/08/2013 03:48 PM, Yumin Qi wrote:
> Hi,
>
>   Thanks for the comments from David and Ioi  ---  I misunderstand the 
> problem, the problem is in shell script in which
>
>   if [...]
>
>   will change result $? since it always be the result of last script 
> cmd.  Now fix by recording the result in a variable.
>
>  http://cr.openjdk.java.net/~minqi/8019583/webrev1
>
> Thanks
> Yumin
>
>
> On 8/6/2013 3:38 PM, Yumin Qi wrote:
>> Please review:
>>
>> http://cr.openjdk.java.net/~minqi/8019583/webrev0/ 
>> <http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>
>>
>> Summary: The test will always pass since TestMT.java will always 
>> return value 0 to shell. Fix by recording failure value and exit with 
>> it.
>>
>> Thanks
>> Yumin
>


From yumin.qi at oracle.com  Thu Aug  8 14:16:09 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 08 Aug 2013 14:16:09 -0700
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
In-Reply-To: <520405E1.20503@oracle.com>
References: <52017AC9.9040809@oracle.com> <5203F619.3020308@oracle.com>
	<520405E1.20503@oracle.com>
Message-ID: <52040A99.6010902@oracle.com>

Thanks Coleen and Ioi for the review!

Yumin
On 8/8/2013 1:56 PM, Coleen Phillimore wrote:
>
> Hi Yumin,
> With the test_env.sh script a lot of things in the case statement are 
> now set by that script, so you don't need lines 56-58.
>
> Also lines 90 and 91 don't match - it doesn't echo what it does.
>
> Otherwise, it looks fine.  I don't need to see the code again after 
> you fix these (but verify the changes don't break anything!)
>
> Thanks,
> Coleen
>
> On 08/08/2013 03:48 PM, Yumin Qi wrote:
>> Hi,
>>
>>   Thanks for the comments from David and Ioi  ---  I misunderstand 
>> the problem, the problem is in shell script in which
>>
>>   if [...]
>>
>>   will change result $? since it always be the result of last script 
>> cmd.  Now fix by recording the result in a variable.
>>
>>  http://cr.openjdk.java.net/~minqi/8019583/webrev1
>>
>> Thanks
>> Yumin
>>
>>
>> On 8/6/2013 3:38 PM, Yumin Qi wrote:
>>> Please review:
>>>
>>> http://cr.openjdk.java.net/~minqi/8019583/webrev0/ 
>>> <http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>
>>>
>>> Summary: The test will always pass since TestMT.java will always 
>>> return value 0 to shell. Fix by recording failure value and exit 
>>> with it.
>>>
>>> Thanks
>>> Yumin
>>
>


From david.holmes at oracle.com  Thu Aug  8 14:18:00 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 09 Aug 2013 07:18:00 +1000
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5203E8D7.107@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com>
Message-ID: <52040B08.8020401@oracle.com>

On 9/08/2013 4:52 AM, Ioi Lam wrote:
> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which apparently
> works differently
> (better?) than the official JDK6 build. Maybe Redhat fixed this in their
> own repo??||

Their hotspot version is much later - hs20 vs hs17

David
-----

> ||
> |
> |==OEL6================================================
> ||
> ||sc11136754 ~$ uname -a||
> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
> ||sc11136754 ~$ type java||
> ||java is hashed (/usr/bin/java)||
> ||sc11136754 ~$ java -version||
> ||java version "1.6.0_22"||
> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
> (rhel-1.41.1.10.4.el6-x86_64)||
> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar test2||
> ||Error occurred during initialization of VM||
> ||java/lang/ClassNotFoundException: error in opening JAR file foo.jar||
> ||
> ==OFFICIAL============================================
> ||
> sc11136754 ~$ /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
> -showversion -cp . -Xbootclasspath/a:foo.jar test2
> java version "1.6.0_22"
> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (exceptions.cpp:367), pid=25167, tid=140510319580928
> #  Error: ExceptionMark destructor expects no pending exceptions
> #
> # JRE version: 6.0_22-b04
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
> linux-amd64 )
> # An error report file with more information is saved as:
> # /home/iklam/hs_err_pid25167.log
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> #
> |
> |======================================================
> ||
> ||- Ioi|
>
> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>> Hi Ioi, David,
>>
>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>> |JDK6 seems to handle this better. I have written a simple
>>> stand-alone test case that doesn't require truncating JAR files in
>>> the JDK:||
>>> ||
>>> ||=========================||
>>> ||/*||
>>> ||javac test2.java||
>>> ||rm -f foo.jar||
>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>> ||touch foo.jar||
>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>> ||*/||
>>> ||
>>> ||public class test2 {||
>>> ||    public static void main(String args[]) {||
>>> ||        try {||
>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>> ||System.out.println(Class.forName("xxx"));||
>>> ||        } catch (Throwable t) {||
>>> ||            t.printStackTrace();||
>>> ||        }||
>>> ||    }||
>>> ||}||
>>> ||=========================||
>>> | |
>>> ||JDK6 works fine, but JDK7 would crash with the second "java -cp .
>>> -Xbootclasspath/a:foo.jar test2" command.||
>>> |
>> |I saw crash with the latest 6 update release with both test cases.
>> The crash seems to be at the same spot.
>> |
>>> |||
>>> ||So I think the correct fix is to restore the JDK6 behavior (not
>>> sure if it's already the same with your patch, but worth checking),
>>> and also add a new jtreg test into hotspot.||
>>> |
>> |I checked the jdk 6 code and those 3 methods which I changed look the
>> same as jdk 8.
>> Sure, I can add a jtreg test.
>> |
>>> |||
>>> ||Thanks||
>>> ||- Ioi||
>>> ||
>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>> |
>>>> |Hi Calvin, ||
>>>> | |
>>>> ||It seems to me that this code has a general problem with
>>>> exceptions. If exceptions can be posted then methods should be
>>>> declared with a last parameter of TRAPS and called with a CHECK_
>>>> macro. The way this code is written it does not seem to expect any
>>>> exceptions to be possible. I would check with Karen on this. ||
>>>> |
>> |I was thinking about that but that would involves a bit more changes.
>> I can give it a try.
>> |
>>>> || |
>>>> ||This addition seems unused: ||
>>>> | |
>>>> ||+   Thread* THREAD = thread; ||
>>>> |
>> |It is required for the THROW_MSG().
>> It won't be needed if the method is declared with TRAPS as the last
>> parameter (I think).
>>
>> thanks,
>> Calvin
>> |
>>>> || |
>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing
>>>> exceptions - don't know what the thought process was there :) ||
>>>> | |
>>>> ||David ||
>>>> | |
>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>> |
>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce similar
>>>>> crash ||
>>>>> ||by trying to load a class from an empty jar which is in the ||
>>>>> ||bootclasspath. The following program can trigger the crash if the ||
>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>> | |
>>>>> ||public class TestForName { ||
>>>>> ||     public static void main(String[] args) { ||
>>>>> ||         try { ||
>>>>> ||             Class cls =
>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>> ||             System.out.println("Class = " + cls.getName()); ||
>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>> ||             cnfe.printStackTrace(); ||
>>>>> ||         } ||
>>>>> ||     } ||
>>>>> ||} ||
>>>>> | |
>>>>> ||The fix also changes the assert() in
>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>> above test ||
>>>>> ||scenario. ||
>>>>> | |
>>>>> ||With the fix, the following ClassNotFoundException will be thrown ||
>>>>> ||instead of a crash: ||
>>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>> ||         at java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>> ||         at java.security.AccessController.doPrivileged(Native
>>>>> Method) ||
>>>>> ||         at
>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>> ||         at
>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>>> ||         at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>> | |
>>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>> | |
>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>> | |
>>>>> ||Tests: ||
>>>>> ||     jprt, vm.quick.testlist ||
>>>>> | |
>>>>> ||thanks, ||
>>>>> ||Calvin ||
>>>>> | |
>>>>> | |
>>>>> |
>>> |
>>> |
>>
>

From david.holmes at oracle.com  Thu Aug  8 14:25:04 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 09 Aug 2013 07:25:04 +1000
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
In-Reply-To: <520405E1.20503@oracle.com>
References: <52017AC9.9040809@oracle.com> <5203F619.3020308@oracle.com>
	<520405E1.20503@oracle.com>
Message-ID: <52040CB0.2040107@oracle.com>

+1 from me.

On 9/08/2013 6:56 AM, Coleen Phillimore wrote:
>
> Hi Yumin,
> With the test_env.sh script a lot of things in the case statement are
> now set by that script, so you don't need lines 56-58.

Regardless of test_env.sh setting variables before you do an exit is 
kind of completely pointless ;-)

Cheers,
David

> Also lines 90 and 91 don't match - it doesn't echo what it does.
>
> Otherwise, it looks fine.  I don't need to see the code again after you
> fix these (but verify the changes don't break anything!)
>
> Thanks,
> Coleen
>
> On 08/08/2013 03:48 PM, Yumin Qi wrote:
>> Hi,
>>
>>   Thanks for the comments from David and Ioi  ---  I misunderstand the
>> problem, the problem is in shell script in which
>>
>>   if [...]
>>
>>   will change result $? since it always be the result of last script
>> cmd.  Now fix by recording the result in a variable.
>>
>>  http://cr.openjdk.java.net/~minqi/8019583/webrev1
>>
>> Thanks
>> Yumin
>>
>>
>> On 8/6/2013 3:38 PM, Yumin Qi wrote:
>>> Please review:
>>>
>>> http://cr.openjdk.java.net/~minqi/8019583/webrev0/
>>> <http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>
>>>
>>> Summary: The test will always pass since TestMT.java will always
>>> return value 0 to shell. Fix by recording failure value and exit with
>>> it.
>>>
>>> Thanks
>>> Yumin
>>
>

From yumin.qi at oracle.com  Thu Aug  8 14:26:36 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 08 Aug 2013 14:26:36 -0700
Subject: RFR: 8019583: [TESTBUG] runtime/7107135 always passes
In-Reply-To: <52040CB0.2040107@oracle.com>
References: <52017AC9.9040809@oracle.com> <5203F619.3020308@oracle.com>
	<520405E1.20503@oracle.com> <52040CB0.2040107@oracle.com>
Message-ID: <52040D0C.9010901@oracle.com>


On 8/8/2013 2:25 PM, David Holmes wrote:
> +1 from me.
>
> On 9/08/2013 6:56 AM, Coleen Phillimore wrote:
>>
>> Hi Yumin,
>> With the test_env.sh script a lot of things in the case statement are
>> now set by that script, so you don't need lines 56-58.
>
> Regardless of test_env.sh setting variables before you do an exit is 
> kind of completely pointless ;-)
>
Thanks, agree that does not make sense.

Yumin
> Cheers,
> David
>
>> Also lines 90 and 91 don't match - it doesn't echo what it does.
>>
>> Otherwise, it looks fine.  I don't need to see the code again after you
>> fix these (but verify the changes don't break anything!)
>>
>> Thanks,
>> Coleen
>>
>> On 08/08/2013 03:48 PM, Yumin Qi wrote:
>>> Hi,
>>>
>>>   Thanks for the comments from David and Ioi  ---  I misunderstand the
>>> problem, the problem is in shell script in which
>>>
>>>   if [...]
>>>
>>>   will change result $? since it always be the result of last script
>>> cmd.  Now fix by recording the result in a variable.
>>>
>>>  http://cr.openjdk.java.net/~minqi/8019583/webrev1
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 8/6/2013 3:38 PM, Yumin Qi wrote:
>>>> Please review:
>>>>
>>>> http://cr.openjdk.java.net/~minqi/8019583/webrev0/
>>>> <http://cr.openjdk.java.net/%7Eminqi/8019583/webrev0/>
>>>>
>>>> Summary: The test will always pass since TestMT.java will always
>>>> return value 0 to shell. Fix by recording failure value and exit with
>>>> it.
>>>>
>>>> Thanks
>>>> Yumin
>>>
>>


From ioi.lam at oracle.com  Thu Aug  8 14:26:54 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 08 Aug 2013 14:26:54 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52040B08.8020401@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
Message-ID: <52040D1E.9000101@oracle.com>

|I found an official version that's closest to the Redhat version 
(OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still crashes.||
||
||sc11136754 ~$ /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java 
-showversion -cp . -Xbootclasspath/a:foo.jar test2||
||java version "1.6.0_25"||
||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
||
||java.lang.ClassNotFoundException ||
|| - klass: 'java/lang/ClassNotFoundException'||
||#||
||# A fatal error has been detected by the Java Runtime Environment:||
||#||
||#  Internal Error (exceptions.cpp:397), pid=29955, tid=140608485558016||
||#  fatal error: ExceptionMark destructor expects no pending exceptions||
||#||
||# JRE version: 6.0_25-b06||
||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode 
linux-amd64 compressed oops)||
||# An error report file with more information is saved as:||
||# /home/iklam/hs_err_pid29955.log||
||#||
||# If you would like to submit a bug report, please visit:||
||#   http://java.sun.com/webapps/bugreport/crash.jsp||
||#||
||Aborted (core dumped)||
|
- Ioi

On 08/08/2013 02:18 PM, David Holmes wrote:
> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which apparently
>> works differently
>> (better?) than the official JDK6 build. Maybe Redhat fixed this in their
>> own repo??||
>
> Their hotspot version is much later - hs20 vs hs17
>
> David
> -----
>
>> ||
>> |
>> |==OEL6================================================
>> ||
>> ||sc11136754 ~$ uname -a||
>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>> ||sc11136754 ~$ type java||
>> ||java is hashed (/usr/bin/java)||
>> ||sc11136754 ~$ java -version||
>> ||java version "1.6.0_22"||
>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>> (rhel-1.41.1.10.4.el6-x86_64)||
>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar 
>> test2||
>> ||Error occurred during initialization of VM||
>> ||java/lang/ClassNotFoundException: error in opening JAR file foo.jar||
>> ||
>> ==OFFICIAL============================================
>> ||
>> sc11136754 ~$ /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>> java version "1.6.0_22"
>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (exceptions.cpp:367), pid=25167, tid=140510319580928
>> #  Error: ExceptionMark destructor expects no pending exceptions
>> #
>> # JRE version: 6.0_22-b04
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>> linux-amd64 )
>> # An error report file with more information is saved as:
>> # /home/iklam/hs_err_pid25167.log
>> #
>> # If you would like to submit a bug report, please visit:
>> # http://java.sun.com/webapps/bugreport/crash.jsp
>> #
>> |
>> |======================================================
>> ||
>> ||- Ioi|
>>
>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>> Hi Ioi, David,
>>>
>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>> |JDK6 seems to handle this better. I have written a simple
>>>> stand-alone test case that doesn't require truncating JAR files in
>>>> the JDK:||
>>>> ||
>>>> ||=========================||
>>>> ||/*||
>>>> ||javac test2.java||
>>>> ||rm -f foo.jar||
>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>> ||touch foo.jar||
>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>> ||*/||
>>>> ||
>>>> ||public class test2 {||
>>>> ||    public static void main(String args[]) {||
>>>> ||        try {||
>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>> ||System.out.println(Class.forName("xxx"));||
>>>> ||        } catch (Throwable t) {||
>>>> ||            t.printStackTrace();||
>>>> ||        }||
>>>> ||    }||
>>>> ||}||
>>>> ||=========================||
>>>> | |
>>>> ||JDK6 works fine, but JDK7 would crash with the second "java -cp .
>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>> |
>>> |I saw crash with the latest 6 update release with both test cases.
>>> The crash seems to be at the same spot.
>>> |
>>>> |||
>>>> ||So I think the correct fix is to restore the JDK6 behavior (not
>>>> sure if it's already the same with your patch, but worth checking),
>>>> and also add a new jtreg test into hotspot.||
>>>> |
>>> |I checked the jdk 6 code and those 3 methods which I changed look the
>>> same as jdk 8.
>>> Sure, I can add a jtreg test.
>>> |
>>>> |||
>>>> ||Thanks||
>>>> ||- Ioi||
>>>> ||
>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>> |
>>>>> |Hi Calvin, ||
>>>>> | |
>>>>> ||It seems to me that this code has a general problem with
>>>>> exceptions. If exceptions can be posted then methods should be
>>>>> declared with a last parameter of TRAPS and called with a CHECK_
>>>>> macro. The way this code is written it does not seem to expect any
>>>>> exceptions to be possible. I would check with Karen on this. ||
>>>>> |
>>> |I was thinking about that but that would involves a bit more changes.
>>> I can give it a try.
>>> |
>>>>> || |
>>>>> ||This addition seems unused: ||
>>>>> | |
>>>>> ||+   Thread* THREAD = thread; ||
>>>>> |
>>> |It is required for the THROW_MSG().
>>> It won't be needed if the method is declared with TRAPS as the last
>>> parameter (I think).
>>>
>>> thanks,
>>> Calvin
>>> |
>>>>> || |
>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing
>>>>> exceptions - don't know what the thought process was there :) ||
>>>>> | |
>>>>> ||David ||
>>>>> | |
>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>> |
>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce similar
>>>>>> crash ||
>>>>>> ||by trying to load a class from an empty jar which is in the ||
>>>>>> ||bootclasspath. The following program can trigger the crash if 
>>>>>> the ||
>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>> | |
>>>>>> ||public class TestForName { ||
>>>>>> ||     public static void main(String[] args) { ||
>>>>>> ||         try { ||
>>>>>> ||             Class cls =
>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>> ||             System.out.println("Class = " + cls.getName()); ||
>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>> ||         } ||
>>>>>> ||     } ||
>>>>>> ||} ||
>>>>>> | |
>>>>>> ||The fix also changes the assert() in
>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>>> above test ||
>>>>>> ||scenario. ||
>>>>>> | |
>>>>>> ||With the fix, the following ClassNotFoundException will be 
>>>>>> thrown ||
>>>>>> ||instead of a crash: ||
>>>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>>>> ||         at 
>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>> ||         at 
>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>> ||         at java.security.AccessController.doPrivileged(Native
>>>>>> Method) ||
>>>>>> ||         at
>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>> ||         at 
>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>> ||         at
>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>>>> ||         at 
>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>> | |
>>>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>> | |
>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>> | |
>>>>>> ||Tests: ||
>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>> | |
>>>>>> ||thanks, ||
>>>>>> ||Calvin ||
>>>>>> | |
>>>>>> | |
>>>>>> |
>>>> |
>>>> |
>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130808/3c942d69/attachment-0001.html 

From john.coomes at oracle.com  Thu Aug  8 11:50:48 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 08 Aug 2013 18:50:48 +0000
Subject: hg: hsx/hotspot-emb/jdk: 73 new changesets
Message-ID: <20130808191623.C33ED48708@hg.openjdk.java.net>

Changeset: 2978c0a543ed
Author:    prr
Date:      2013-07-22 12:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2978c0a543ed

7196866: CTW fails on all Solaris platforms
Reviewed-by: prr, jrose, twisti, kvn

! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/java2d/x11/XRBackendNative.c

Changeset: 784589c7bc55
Author:    vadim
Date:      2013-07-24 13:38 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/784589c7bc55

8008782: NPE in TrueTypeGlyphMapper
Reviewed-by: bae, prr

! src/share/classes/sun/font/TrueTypeFont.java

Changeset: db2e3a686cf3
Author:    jchen
Date:      2013-07-24 12:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/db2e3a686cf3

8011709: [parfait] False positive: memory leak in jdk/src/share/native/sun/font/layout/CanonShaping.cpp
Reviewed-by: jgodinez, prr

! src/share/native/sun/font/layout/CanonShaping.cpp

Changeset: c2e27e7a42ae
Author:    jchen
Date:      2013-07-24 13:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c2e27e7a42ae

8005126: [parfait] #418 - #428 XRBackendNative.c Integer overflow
Reviewed-by: prr, vadim

! src/solaris/native/sun/java2d/x11/XRBackendNative.c

Changeset: 833f05116f7b
Author:    bae
Date:      2013-07-25 17:14 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/833f05116f7b

8019201: Regression: java.awt.image.ConvolveOp throws java.awt.image.ImagingOpException
Reviewed-by: prr

! src/share/native/sun/awt/medialib/awt_ImagingLib.c
+ test/sun/awt/image/ImagingLib/SamePackingTypeTest.java

Changeset: a8b9df782017
Author:    serb
Date:      2013-07-26 21:18 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a8b9df782017

7190349: [macosx] Text (Label) is incorrectly drawn with a rotated g2d
8013569: [macosx] JLabel preferred size incorrect on retina displays with non-default font size
Reviewed-by: prr

! src/macosx/classes/sun/font/CStrike.java
! src/macosx/native/sun/font/AWTStrike.h
! src/macosx/native/sun/font/AWTStrike.m
! src/macosx/native/sun/font/CGGlyphImages.m
+ test/java/awt/Graphics2D/DrawString/DrawRotatedString.java
+ test/java/awt/Graphics2D/IncorrectTextSize/IncorrectTextSize.java

Changeset: 467a0c21790b
Author:    jgodinez
Date:      2013-07-26 15:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/467a0c21790b

8020208: NullPointerException at sun.print.Win32PrintService.getMediaPrintables
Reviewed-by: jchen, prr

! src/windows/classes/sun/print/Win32PrintService.java

Changeset: 56c6f9a9653d
Author:    jgodinez
Date:      2013-07-26 15:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/56c6f9a9653d

8016343: [macosx] Print job goes to default printer regardless of chosen printer
Reviewed-by: jchen, prr

! src/share/classes/sun/print/PSPrinterJob.java
! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintJob.java
! test/javax/print/DialogMargins.java

Changeset: 1c48544c3da9
Author:    lana
Date:      2013-07-26 15:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1c48544c3da9

Merge

- src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties
- src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- test/java/util/Collections/EmptySortedSet.java

Changeset: 921338e44ba7
Author:    lana
Date:      2013-07-26 17:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/921338e44ba7

Merge


Changeset: 046025f78ea8
Author:    jgodinez
Date:      2013-07-30 13:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/046025f78ea8

8021835: Fix for 8016343 will not compile on Windows.
Reviewed-by: jchen, prr

! src/share/classes/sun/print/PSPrinterJob.java

Changeset: 7f0e569c5a66
Author:    bae
Date:      2013-07-31 13:11 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7f0e569c5a66

8020983: OutOfMemoryError caused by non garbage collected JPEGImageWriter Instances
Reviewed-by: prr, flar

! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
+ test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java

Changeset: 607ad960fe24
Author:    malenkov
Date:      2013-07-22 15:36 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/607ad960fe24

8019975: closed/javax/swing/JFileChooser/4966171/bug4966171.java throws java.io.NotSerializableException: javax.swing.plaf.basic.BasicFileChooserUI$AcceptAllFileFilter
Reviewed-by: alexsch

! src/share/classes/javax/swing/JFileChooser.java

Changeset: 3cbe376233a9
Author:    malenkov
Date:      2013-07-22 20:33 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3cbe376233a9

8015926: NPE when using SynthTreeUI's expandPath()
Reviewed-by: alexsch

! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java
+ test/javax/swing/plaf/synth/Test8015926.java

Changeset: bdad697c03aa
Author:    pchelko
Date:      2013-07-23 13:09 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bdad697c03aa

7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session)
Reviewed-by: art, anthony

! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java

Changeset: 99ee6ddab113
Author:    serb
Date:      2013-07-24 17:14 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/99ee6ddab113

8017189: [macosx] AWT program menu disabled on Mac
Reviewed-by: leonidr, anthony

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.h
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/CMenuBar.m

Changeset: 7bd6eda2d217
Author:    leonidr
Date:      2013-07-26 16:22 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7bd6eda2d217

8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working
Reviewed-by: anthony, serb

! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java
! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/CMenuItem.m

Changeset: 65c90209edbb
Author:    lana
Date:      2013-07-26 15:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/65c90209edbb

Merge

- src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties
- src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- test/java/util/Collections/EmptySortedSet.java

Changeset: 37016eaea5d2
Author:    serb
Date:      2013-07-29 16:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/37016eaea5d2

6230360: Spelling mistake in documentation for AWT: 1.4, 1.5, 1.6, 1.7
Reviewed-by: malenkov, art

! src/share/classes/java/awt/AWTException.java

Changeset: bf80c2965a84
Author:    malenkov
Date:      2013-07-29 18:48 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bf80c2965a84

8010782: clean up source files containing carriage return characters
Reviewed-by: alexsch, art

! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth.properties

Changeset: 1e482f58c747
Author:    ant
Date:      2013-07-30 16:15 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1e482f58c747

8020927: JLightweightFrame API should export layout properties change notifications
Reviewed-by: anthony

! src/share/classes/sun/swing/JLightweightFrame.java
! src/share/classes/sun/swing/LightweightContent.java

Changeset: 336a94dbecb5
Author:    malenkov
Date:      2013-07-30 17:46 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/336a94dbecb5

8015300: JComboBox text sometimes become selected, sometimes not (Windows LAF)
Reviewed-by: alexsch, serb

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java
+ test/javax/swing/JComboBox/8015300/Test8015300.java

Changeset: 726ac8f75b54
Author:    lana
Date:      2013-07-31 12:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/726ac8f75b54

Merge


Changeset: 6e10d93273d0
Author:    juh
Date:      2013-07-18 10:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6e10d93273d0

8020426: Fix doclint accessibility issues in java.io
Reviewed-by: mduigou, darcy, chegar

! src/share/classes/java/io/DataInput.java
! src/share/classes/java/io/File.java
! src/share/classes/java/io/ObjectStreamField.java
! src/share/classes/java/io/RandomAccessFile.java

Changeset: b39797bb86c0
Author:    sherman
Date:      2013-07-18 11:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b39797bb86c0

8016025: JSR 310 DateTime API Updates IV
8020418: Cleanup of -Xlint warnings in java.time
8016623: test/java/time/format/TestDateTimeTextProvider.java failing
Summary: Integration of JSR310 Date/Time API update IV
Reviewed-by: sherman
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com, chand.basha at oracle.com

! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/Month.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoDateImpl.java
! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/Era.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/chrono/package-info.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/time/format/DateTimePrintContext.java
! src/share/classes/java/time/format/Parsed.java
! src/share/classes/java/time/temporal/ChronoField.java
! src/share/classes/java/time/temporal/ChronoUnit.java
! src/share/classes/java/time/temporal/IsoFields.java
! src/share/classes/java/time/temporal/JulianFields.java
! src/share/classes/java/time/temporal/Temporal.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
! src/share/classes/java/time/temporal/TemporalField.java
! src/share/classes/java/time/temporal/TemporalUnit.java
! src/share/classes/java/time/temporal/ValueRange.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/lib/hijrah-config-umalqura.properties
! test/java/time/tck/java/time/MockSimplePeriod.java
! test/java/time/tck/java/time/TCKClock_Fixed.java
! test/java/time/tck/java/time/TCKDayOfWeek.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKMonth.java
! test/java/time/tck/java/time/TCKMonthDay.java
! test/java/time/tck/java/time/TCKOffsetDateTime.java
! test/java/time/tck/java/time/TCKOffsetTime.java
! test/java/time/tck/java/time/TCKPeriod.java
! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZoneId.java
! test/java/time/tck/java/time/TCKZonedDateTime.java
! test/java/time/tck/java/time/chrono/CopticDate.java
! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java
! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java
! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java
! test/java/time/tck/java/time/chrono/TCKChronology.java
! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java
! test/java/time/tck/java/time/chrono/TCKHijrahEra.java
! test/java/time/tck/java/time/chrono/TCKIsoChronology.java
! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java
! test/java/time/tck/java/time/chrono/TCKJapaneseEra.java
! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java
! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java
+ test/java/time/tck/java/time/format/TCKFormatStyle.java
+ test/java/time/tck/java/time/format/TCKResolverStyle.java
+ test/java/time/tck/java/time/format/TCKSignStyle.java
! test/java/time/tck/java/time/format/TCKTextStyle.java
! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java
+ test/java/time/tck/java/time/temporal/TCKChronoField.java
+ test/java/time/tck/java/time/temporal/TCKChronoUnit.java
! test/java/time/tck/java/time/temporal/TCKWeekFields.java
! test/java/time/tck/java/time/zone/TCKZoneRules.java
! test/java/time/test/java/time/MockSimplePeriod.java
! test/java/time/test/java/time/chrono/TestChronoLocalDate.java
! test/java/time/test/java/time/chrono/TestExampleCode.java
! test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java
! test/java/time/test/java/time/chrono/TestJapaneseChronology.java
! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
! test/java/time/test/java/time/format/TestDateTimeTextProvider.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/java/time/test/java/time/format/TestNumberPrinter.java
! test/java/time/test/java/time/format/TestReducedPrinter.java
! test/java/time/test/java/time/temporal/MockFieldNoValue.java
! test/java/time/test/java/time/temporal/MockFieldValue.java

Changeset: 2323b973adaa
Author:    darcy
Date:      2013-07-18 23:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2323b973adaa

8020810: Typo in javadoc for Class.toGenericString()
Reviewed-by: dholmes

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/reflect/Parameter.java

Changeset: e6aeeec33e53
Author:    uta
Date:      2013-07-19 12:53 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e6aeeec33e53

8016579: (process) IOException thrown by ProcessBuilder.start() method is incorrectly encoded
Reviewed-by: martin, dxu

! src/share/native/java/io/io_util.c
! src/windows/native/java/io/io_util_md.c
! src/windows/native/java/lang/ProcessImpl_md.c

Changeset: e013b32118af
Author:    darcy
Date:      2013-07-19 09:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e013b32118af

8020948: Fix doclint issues in misc package-info.java files
Reviewed-by: dholmes, chegar

! src/share/classes/java/nio/file/attribute/package-info.java
! src/share/classes/java/util/function/package-info.java

Changeset: 4bd04969a228
Author:    darcy
Date:      2013-07-20 11:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4bd04969a228

8020971: Fix doclint issues in java.nio.*
Reviewed-by: lancea

! src/share/classes/java/nio/channels/package-info.java
! src/share/classes/java/nio/charset/Charset.java
! src/share/classes/java/nio/charset/MalformedInputException.java
! src/share/classes/java/nio/charset/UnmappableCharacterException.java
! src/share/classes/java/nio/file/package-info.java

Changeset: dcd89e60051a
Author:    khazra
Date:      2013-07-22 15:24 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/dcd89e60051a

8020498: Crash when both libnet.so and libmawt.so are loaded
Reviewed-by: chegar, dsamersoff

! src/share/native/java/net/net_util.c

Changeset: a3a2889b1049
Author:    dl
Date:      2013-07-22 15:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a3a2889b1049

8020976: Ensure consistent insertion for ConcurrentHashMap
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java

Changeset: a6cbb9808e4b
Author:    mduigou
Date:      2013-07-22 12:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a6cbb9808e4b

6799426: Adds constructor PriorityQueue(Comparator)
Reviewed-by: lancea

! src/share/classes/java/util/PriorityQueue.java

Changeset: 7716beb127d4
Author:    darcy
Date:      2013-07-22 22:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7716beb127d4

8021109: Add serialVersionUID to LambdaConversionException.java
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/LambdaConversionException.java

Changeset: 6f3b940fe9f8
Author:    igerasim
Date:      2013-07-23 18:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6f3b940fe9f8

8016838: improvement of RedefineBigClass and RetransformBigClass tests
Reviewed-by: dcubed

! test/ProblemList.txt
! test/java/lang/instrument/RedefineBigClass.sh
! test/java/lang/instrument/RedefineBigClassApp.java
! test/java/lang/instrument/RetransformBigClass.sh
! test/java/lang/instrument/RetransformBigClassApp.java

Changeset: 8156630c1ed3
Author:    mduigou
Date:      2013-07-23 13:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8156630c1ed3

8019840: Spec updates for java.util.function
Reviewed-by: mduigou, chegar
Contributed-by: brian.goetz at oracle.com

! src/share/classes/java/util/function/BiConsumer.java
! src/share/classes/java/util/function/BiFunction.java
! src/share/classes/java/util/function/BiPredicate.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/BooleanSupplier.java
! src/share/classes/java/util/function/Consumer.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java
! src/share/classes/java/util/function/DoubleConsumer.java
! src/share/classes/java/util/function/DoubleFunction.java
! src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/DoubleSupplier.java
! src/share/classes/java/util/function/DoubleToIntFunction.java
! src/share/classes/java/util/function/DoubleToLongFunction.java
! src/share/classes/java/util/function/DoubleUnaryOperator.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntBinaryOperator.java
! src/share/classes/java/util/function/IntConsumer.java
! src/share/classes/java/util/function/IntFunction.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/IntSupplier.java
! src/share/classes/java/util/function/IntToDoubleFunction.java
! src/share/classes/java/util/function/IntToLongFunction.java
! src/share/classes/java/util/function/IntUnaryOperator.java
! src/share/classes/java/util/function/LongBinaryOperator.java
! src/share/classes/java/util/function/LongConsumer.java
! src/share/classes/java/util/function/LongFunction.java
! src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/LongSupplier.java
! src/share/classes/java/util/function/LongToDoubleFunction.java
! src/share/classes/java/util/function/LongToIntFunction.java
! src/share/classes/java/util/function/LongUnaryOperator.java
! src/share/classes/java/util/function/ObjDoubleConsumer.java
! src/share/classes/java/util/function/ObjIntConsumer.java
! src/share/classes/java/util/function/ObjLongConsumer.java
! src/share/classes/java/util/function/Predicate.java
! src/share/classes/java/util/function/Supplier.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java
! src/share/classes/java/util/function/ToDoubleFunction.java
! src/share/classes/java/util/function/ToIntBiFunction.java
! src/share/classes/java/util/function/ToIntFunction.java
! src/share/classes/java/util/function/ToLongBiFunction.java
! src/share/classes/java/util/function/ToLongFunction.java
! src/share/classes/java/util/function/UnaryOperator.java
! src/share/classes/java/util/function/package-info.java

Changeset: 012996e9259f
Author:    mduigou
Date:      2013-07-23 13:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/012996e9259f

Merge


Changeset: 187a1f2613c0
Author:    sjiang
Date:      2013-07-24 15:47 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/187a1f2613c0

8016221: A unit test should not use a fix port to run a jmx connector
Reviewed-by: jbachorik, dfuchs

! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanDoubleInvocationTest.java
! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanInvocationTest.java
! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java

Changeset: f9224fb49890
Author:    juh
Date:      2013-07-24 12:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f9224fb49890

8016916: UnstructuredName should support DirectoryString
Reviewed-by: mullan

! src/share/classes/sun/security/pkcs/PKCS9Attribute.java
! src/share/classes/sun/security/tools/keytool/Main.java
+ test/sun/security/pkcs/pkcs9/UnstructuredName.java

Changeset: fd1b5adcfdf0
Author:    chegar
Date:      2013-07-24 22:52 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fd1b5adcfdf0

8021261: ProblemList.txt updates (7/2013)
Reviewed-by: alanb, mcimadamore

! test/ProblemList.txt

Changeset: a834ab2c1354
Author:    mullan
Date:      2013-07-25 10:58 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a834ab2c1354

8010748: Add PKIXRevocationChecker NO_FALLBACK option and improve SOFT_FAIL option
Reviewed-by: vinnie

! src/share/classes/java/security/cert/PKIXRevocationChecker.java
! src/share/classes/sun/security/provider/certpath/OCSP.java
! src/share/classes/sun/security/provider/certpath/OCSPResponse.java
! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! src/share/classes/sun/security/provider/certpath/ReverseState.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java
! test/java/security/cert/PKIXRevocationChecker/UnitTest.java

Changeset: 22a391706a0b
Author:    mullan
Date:      2013-07-25 11:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/22a391706a0b

Merge

- make/sun/xawt/ToBin.java
- makefiles/sun/awt/X11/ToBin.java
- src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties
- src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java
- src/share/classes/java/security/acl/package.html
- src/share/classes/java/security/cert/package.html
- src/share/classes/java/security/interfaces/package.html
- src/share/classes/java/security/package.html
- src/share/classes/java/security/spec/package.html
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- src/share/classes/sun/misc/Hashing.java
- src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java
- src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
- src/solaris/classes/sun/awt/X11/XIconInfo.java
- src/solaris/classes/sun/awt/X11/security-icon-bw16.png
- src/solaris/classes/sun/awt/X11/security-icon-bw24.png
- src/solaris/classes/sun/awt/X11/security-icon-bw32.png
- src/solaris/classes/sun/awt/X11/security-icon-bw48.png
- src/solaris/classes/sun/awt/X11/security-icon-interim16.png
- src/solaris/classes/sun/awt/X11/security-icon-interim24.png
- src/solaris/classes/sun/awt/X11/security-icon-interim32.png
- src/solaris/classes/sun/awt/X11/security-icon-interim48.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow16.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow24.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow32.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow48.png
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties
- test/java/lang/invoke/7196190/MHProxyTest.java
- test/java/util/Collections/EmptySortedSet.java
- test/java/util/Comparators/BasicTest.java
- test/sun/misc/Hashing.java
- test/sun/security/krb5/auto/ReplayCache.java

Changeset: 21120e3682ef
Author:    darcy
Date:      2013-07-25 09:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/21120e3682ef

8021408: Fix misc doclint issues in java.util and java.io
Reviewed-by: dholmes, chegar, psandoz

! src/share/classes/java/io/ObjectInputStream.java
! src/share/classes/java/io/ObjectOutputStream.java
! src/share/classes/java/util/jar/Attributes.java
! src/share/classes/java/util/jar/JarEntry.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/stream/StreamSupport.java

Changeset: 690dcbaa69b7
Author:    chegar
Date:      2013-07-25 19:37 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/690dcbaa69b7

8021417: Fix doclint issues in java.util.concurrent
Reviewed-by: chegar, lancea
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/share/classes/java/util/concurrent/ExecutorService.java
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/TimeUnit.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java

Changeset: 9cd5159fa870
Author:    chegar
Date:      2013-07-25 19:45 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9cd5159fa870

8021421: More doclint fixes in java.net
Reviewed-by: lancea, darcy

! src/share/classes/java/net/URI.java

Changeset: 662ec7782102
Author:    joehw
Date:      2013-07-25 13:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/662ec7782102

8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)
Reviewed-by: chegar, lancea, dfuchs

+ test/javax/xml/jaxp/parsers/8021148/JAXPSAXParserTest.java
+ test/javax/xml/jaxp/parsers/8021148/TestBase.java

Changeset: 1744a32d3db3
Author:    mullan
Date:      2013-07-25 20:12 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1744a32d3db3

8012288: XML DSig API allows wrong tag names and extra elements in SignedInfo
Reviewed-by: xuelei

! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java

Changeset: 4100ab44ba4f
Author:    mullan
Date:      2013-07-25 20:30 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4100ab44ba4f

Merge


Changeset: 86a827321c39
Author:    darcy
Date:      2013-07-25 20:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/86a827321c39

8021429: Fix lint warnings in java.lang.ref
Reviewed-by: lancea, mduigou, alanb

! src/share/classes/java/lang/ref/FinalReference.java
! src/share/classes/java/lang/ref/Finalizer.java
! src/share/classes/java/lang/ref/Reference.java
! src/share/classes/java/lang/ref/ReferenceQueue.java

Changeset: 6cc15a808b93
Author:    peytoia
Date:      2013-07-26 17:22 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6cc15a808b93

8021108: Clean up doclint warnings and errors in java.text package
Reviewed-by: darcy, okutsu

! src/share/classes/java/text/Annotation.java
! src/share/classes/java/text/AttributedCharacterIterator.java
! src/share/classes/java/text/Bidi.java
! src/share/classes/java/text/BreakIterator.java
! src/share/classes/java/text/ChoiceFormat.java
! src/share/classes/java/text/CollationElementIterator.java
! src/share/classes/java/text/CollationKey.java
! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/FieldPosition.java
! src/share/classes/java/text/Format.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/Normalizer.java
! src/share/classes/java/text/NumberFormat.java
! src/share/classes/java/text/ParseException.java
! src/share/classes/java/text/ParsePosition.java
! src/share/classes/java/text/RuleBasedCollator.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/text/StringCharacterIterator.java

Changeset: 952476b80fa7
Author:    jbachorik
Date:      2013-07-26 10:12 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/952476b80fa7

8020875: java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently
Reviewed-by: dfuchs, chegar

! test/java/lang/management/ThreadMXBean/ResetPeakThreadCount.java

Changeset: 7ae061cfd4be
Author:    juh
Date:      2013-07-26 14:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7ae061cfd4be

8019544: Need to run ProviderTest.java in othervm mode.
Reviewed-by: wetmore, xuelei, vinnie
Contributed-by: rajan.halade at oracle.com

! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java

Changeset: 25575c3c209d
Author:    lana
Date:      2013-07-26 14:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/25575c3c209d

Merge


Changeset: 9f9ffe6be557
Author:    lana
Date:      2013-07-26 15:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9f9ffe6be557

Merge


Changeset: f056728871f8
Author:    mduigou
Date:      2013-07-26 17:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f056728871f8

8021601: Add unit test for PriorityQueue(Comparator) constructor
Reviewed-by: darcy, alanb

! src/share/classes/java/util/PriorityQueue.java
! test/java/util/PriorityQueue/RemoveContains.java

Changeset: d4b2436892c8
Author:    bpb
Date:      2013-07-26 17:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d4b2436892c8

8014319: Faster division of large integers
Summary: Implement Burnickel-Ziegler division algorithm in BigInteger
Reviewed-by: bpb, martin
Contributed-by: Tim Buktu <tbuktu at hotmail.com>

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java

Changeset: a1c01457cf6c
Author:    bpb
Date:      2013-07-26 17:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a1c01457cf6c

8020641: Clean up some code style in recent BigInteger contributions
Summary: Some minor cleanup to adhere better to Java coding conventions.
Reviewed-by: darcy
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java

Changeset: eb1dc65162e8
Author:    darcy
Date:      2013-07-27 10:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/eb1dc65162e8

8021609: Fix doclint issues in java.nio.charset
Reviewed-by: alanb

! src/share/classes/java/nio/charset/Charset-X-Coder.java.template

Changeset: 5d4a35823071
Author:    mduigou
Date:      2013-07-27 12:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5d4a35823071

8021588: Remove explicit othervm execution from jdk/test/Makefile
Reviewed-by: alanb

! test/Makefile

Changeset: 24bda55fca48
Author:    sundar
Date:      2013-07-29 21:39 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/24bda55fca48

8021773: print function as defined by jrunscript's init.js script is incompatible with nashorn's definition
Reviewed-by: hannesw, lagergren

! src/share/classes/com/sun/tools/script/shell/init.js

Changeset: e83fc6d9cf03
Author:    psandoz
Date:      2013-07-29 19:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e83fc6d9cf03

8020156: TreeMap.values().spliterator() does not report ORDERED
8020009: TreeMap.entrySet().spliterator() reports SORTED + null comparator but the elements are not Comparable
Reviewed-by: mduigou

! src/share/classes/java/util/TreeMap.java
+ test/java/util/Spliterator/SpliteratorCharacteristics.java

Changeset: c042fd498f79
Author:    ascarpino
Date:      2013-07-19 11:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c042fd498f79

8012971: PKCS11Test hiding exception failures
Reviewed-by: vinnie, valeriep

! test/ProblemList.txt
! test/sun/security/pkcs11/PKCS11Test.java
! test/sun/security/pkcs11/SecmodTest.java

Changeset: e47569593fa0
Author:    ascarpino
Date:      2013-07-29 13:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e47569593fa0

8020424: The NSS version should be detected before running crypto tests
Reviewed-by: valeriep

! test/ProblemList.txt
! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java
! test/sun/security/pkcs11/PKCS11Test.java
+ test/sun/security/pkcs11/README
! test/sun/security/pkcs11/ec/ReadCertificates.java
! test/sun/security/pkcs11/ec/TestCurves.java
! test/sun/security/pkcs11/ec/TestECDH.java
! test/sun/security/pkcs11/ec/TestECDH2.java
! test/sun/security/pkcs11/ec/TestECDSA.java
! test/sun/security/pkcs11/ec/TestECDSA2.java
! test/sun/security/pkcs11/ec/TestECGenSpec.java
! test/sun/security/pkcs11/ec/TestKeyFactory.java

Changeset: 613cc7beba64
Author:    xuelei
Date:      2013-07-29 19:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/613cc7beba64

8021841: Remove SSLEngineDeadlock.java from problem list
Reviewed-by: wetmore

! test/ProblemList.txt

Changeset: c76f89695c90
Author:    juh
Date:      2013-07-30 11:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c76f89695c90

8021833: javadoc cleanup in java.net
Summary: <code> and <tt> converted to {@code }; package.html to package-info.java
Reviewed-by: darcy, chegar

! src/share/classes/java/net/Authenticator.java
! src/share/classes/java/net/ContentHandler.java
! src/share/classes/java/net/ContentHandlerFactory.java
! src/share/classes/java/net/CookieHandler.java
! src/share/classes/java/net/CookieManager.java
! src/share/classes/java/net/CookiePolicy.java
! src/share/classes/java/net/CookieStore.java
! src/share/classes/java/net/DatagramPacket.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/DatagramSocketImpl.java
! src/share/classes/java/net/DatagramSocketImplFactory.java
! src/share/classes/java/net/FileNameMap.java
! src/share/classes/java/net/HttpCookie.java
! src/share/classes/java/net/HttpRetryException.java
! src/share/classes/java/net/HttpURLConnection.java
! src/share/classes/java/net/IDN.java
! src/share/classes/java/net/Inet4Address.java
! src/share/classes/java/net/Inet6Address.java
! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/net/InetSocketAddress.java
! src/share/classes/java/net/InterfaceAddress.java
! src/share/classes/java/net/JarURLConnection.java
! src/share/classes/java/net/MalformedURLException.java
! src/share/classes/java/net/MulticastSocket.java
! src/share/classes/java/net/NetPermission.java
! src/share/classes/java/net/NetworkInterface.java
! src/share/classes/java/net/PasswordAuthentication.java
! src/share/classes/java/net/PortUnreachableException.java
! src/share/classes/java/net/ProtocolException.java
! src/share/classes/java/net/Proxy.java
! src/share/classes/java/net/ProxySelector.java
! src/share/classes/java/net/ResponseCache.java
! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/Socket.java
! src/share/classes/java/net/SocketException.java
! src/share/classes/java/net/SocketImpl.java
! src/share/classes/java/net/SocketImplFactory.java
! src/share/classes/java/net/SocketInputStream.java
! src/share/classes/java/net/SocketOptions.java
! src/share/classes/java/net/SocketOutputStream.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/net/URI.java
! src/share/classes/java/net/URISyntaxException.java
! src/share/classes/java/net/URL.java
! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/net/URLDecoder.java
! src/share/classes/java/net/URLEncoder.java
! src/share/classes/java/net/URLStreamHandler.java
! src/share/classes/java/net/URLStreamHandlerFactory.java
! src/share/classes/java/net/UnknownHostException.java
! src/share/classes/java/net/UnknownServiceException.java
+ src/share/classes/java/net/package-info.java
- src/share/classes/java/net/package.html

Changeset: 8bc1bbd5b659
Author:    sherman
Date:      2013-07-30 14:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8bc1bbd5b659

8021767: test/java/time/tck/java/time/format/TCKFormatStyle.java failing
Summary: Correct to use fixed locale, not locale of test environment
Reviewed-by: alanb, okutsu
Contributed-by: roger.riggs at oracle.com

! test/java/time/tck/java/time/format/TCKFormatStyle.java

Changeset: 09a77a1bdbc3
Author:    henryjen
Date:      2013-07-30 15:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/09a77a1bdbc3

8020977: StringJoiner merges with itself not as expected
Reviewed-by: psandoz, chegar, mduigou, smarks

! src/share/classes/java/util/StringJoiner.java
! test/java/util/StringJoiner/MergeTest.java

Changeset: 76d88a752a03
Author:    psandoz
Date:      2013-07-30 11:32 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/76d88a752a03

8021863: Stream.concat incorrectly calculates unsized state
Reviewed-by: chegar

! src/share/classes/java/util/stream/Streams.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java

Changeset: d30f357c6050
Author:    psandoz
Date:      2013-07-30 14:03 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d30f357c6050

8021883: j.u.Random/RandomStream.java test needs more robust timeout duration
Reviewed-by: chegar

! test/java/util/Random/RandomStreamTest.java

Changeset: 5561b34f6d4c
Author:    bpb
Date:      2013-07-30 10:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5561b34f6d4c

8020539: Clean up doclint problems in java.util package, part 2
Summary: Clean up doclint errors and warnings in classes in java.util
Reviewed-by: darcy, chegar
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! src/share/classes/java/util/List.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/Random.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/java/util/StringJoiner.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/UUID.java
! src/share/classes/java/util/Vector.java

Changeset: 4bd51f6268f4
Author:    rbackman
Date:      2013-07-24 10:57 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4bd51f6268f4

8006324: [TEST_BUG] sun/invoke/util/ValueConversionsTest.java should be modified
Reviewed-by: kvn, twisti

! test/sun/invoke/util/ValueConversionsTest.java

Changeset: 0741b19835b0
Author:    lana
Date:      2013-07-31 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0741b19835b0

Merge

- src/share/classes/java/net/package.html

Changeset: 8ed8e2b4b90e
Author:    lana
Date:      2013-08-06 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8ed8e2b4b90e

Merge


Changeset: e057cddf0d6c
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e057cddf0d6c

Added tag jdk8-b102 for changeset 8ed8e2b4b90e

! .hgtags


From vladimir.kozlov at oracle.com  Thu Aug  8 14:37:12 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 08 Aug 2013 14:37:12 -0700
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <5202691E.6020500@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
	<52002E68.6080901@oracle.com> <5202691E.6020500@oracle.com>
Message-ID: <52040F88.9070406@oracle.com>

On 8/7/13 8:34 AM, harold seigel wrote:
> Hi Vladimir,
>
> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>> Harold,
>>
>> Note, on SPARC set() could generate up to 8 instructions to load
>> 64-bit constant into register. So I am not sure that it will be faster
>> than load.
> We thought it would be faster because it doesn't need to load anything
> from memory.

For good value (0x800000000) it should use only 2-3 instructions.
I think you can keep using set().

>>
>> I can't find where in CDS you store information about compressed klass
>> pointers and compressed oops parameters which were used during dump?
>> How you verify that correct parameters/flags are ussed when such CDS
>> is used later?
> No compressed klass pointers nor compressed oops get written to the
> archive.  So, the compressed klass pointers and compressed oops
> parameters do not need to be recorded in the archive.

So you are saying that all klass pointers (references to klasses) in 
metadata structures in metaspace are full. And klass pointers are only 
compressed in java object headers (which are not part of CDS). Right?
And you don't care about UseCompressedOops and 
UseCompressedKlassPointers flags settings when you dump it into archive. 
The only limit is:

Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total

Then I don't understand why you can't use/load CDS archive when coop or 
compklass are off:

 > If coop is turned off then CDS cannot be used.  CDS will only be
 > supported if both UseCompressedOops and UseCompressedKlassPointers are
 > TRUE.

Also based on code in arguments.cpp it is allowed to specify 
-XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command line:

1466     // Turn on UseCompressedKlassPointers too
1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
1469     }

Did you tested such combination?

>>
>> set_narrow_klass_base_and_shift() and
>> can_use_cds_with_metaspace_addr() have the same code for
>> UseSharedSpaces. It would be nice to have only one copy. Call
>> can_use_cds_with_metaspace_addr() from
>> set_narrow_klass_base_and_shift() ?
> I could add new inlined methods that determine the higher_address and
> lower_base when UseSharedSpaces is true and have them called from
> set_narrow_klass_base_and_shift() and
> can_use_cds_with_metaspace_addr().  Would that be worth doing?

I tried several approaches but your implementation is more clean. So I 
agree to keep what you have now.


Also I found strange assert which should always fail (old code in 
global_initialize() in metaspace.cpp):

2959     if (UseSharedSpaces) {
...
2969       } else {
2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
2971                "archive file not closed or shared spaces not 
disabled.");

Thanks,
Vladimir

>>
>> I see that you unconditionally set comp klass ptr base and shift for
>> DumpSharedSpaces. Should you do the check similar to
>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>> don't even check UseCompressedKlassPointers.
> I don't think the checks are needed because the information written to
> the archive is not affected by the size of the class metaspace.
>
> Also, I recently added code to arguments.cpp that will generate an error
> if UseCompressedOops or UseCompressedKlassPointers is turned off and
> DumpSharedSpaces is on.
>>
>> Why you have next limitation? What if coop can't be used because of
>> big heap?:
>>
>> +     // UseCompressedOops and UseCompressedKlassPointers must be on
>> for UseSharedSpaces.
>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>> +       no_shared_spaces();
> If coop is turned off then CDS cannot be used.  CDS will only be
> supported if both UseCompressedOops and UseCompressedKlassPointers are
> TRUE.
>>
>> Could you move UseCompressedKlassPointers code in arguments.cpp into
>> separate method similar to set_use_compressed_oops()?
> Done.
>>
>> About new tests.
>> The first test in CDSCompressedKPtrsError misses
>> -XX:+UseCompressedOops flag.
> Fixed.
>>
>> Could you also test cross flags combinations?:
>>
>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
> Done.
>>
>> It would be nice to have test to check ClassMetaspaceSize value range.
>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint
>> or maxuint.
> A member of our runtime SQE group is writing additional tests.  I'll ask
> him to write a ClassMetaspaceSize range test.
>
> We chose 3Gb because we thought it was a sufficiently large size.
>>
>>
>> About code style, indention. We align next line to corresponding part
>> of previous line if we need to split a line. And sometimes it is
>> better to keep one long line. I understand some of them were before
>> your changes but, please, clean up at lest ones you touched.
> Done.
>>
>> Cases in metaspace.cpp:
>>
>> 2263   assert(raw_word_size >= min_size,
>> 2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<"
>> SIZE_FORMAT, word_size, min_size));
>>
>>
>> 2485   if (Metaspace::using_class_space() &&
>> 2486     (Metaspace::class_space_list() != NULL)) {
>>
>>
>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>> 2575                       (Metaspace::using_class_space() ?
>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>> 2577 Metaspace::space_list()->virtual_space_total();
>>
>>
>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>> SIZE_FORMAT ", "
>> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT ", "
>> 2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT
>> ", "
>> 2697                            "large count " SIZE_FORMAT,
>> 2698              cls_specialized_count, cls_specialized_waste,
>> 2699              cls_small_count, cls_small_waste,
>> 2700              cls_medium_count, cls_medium_waste,
>> cls_humongous_count);
>>
>>
>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G > addr) &&
>> 2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>
>>
>> 2889         vm_exit_during_initialization(err_msg(
>> 2890           "Could not allocate metaspace: %d bytes",
>> 2891           class_metaspace_size()));
>>
>>
>> 3107     return using_class_space() ?
>> 3108       class_vsm()->sum_used_in_chunks_in_use() : 0;
>>
>>
>> 3157     if (is_class && using_class_space()) {
>> 3158        class_vsm()->deallocate(ptr, word_size);
>>
>>
>> 3305   return space_list()->contains(ptr) ||
>> 3306     (using_class_space() && class_space_list()->contains(ptr));
>>
>> metaspace.hpp:
>>
>>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
>>  271       (Metaspace::using_class_space() ?
>>  272         _allocated_capacity_words[Metaspace::ClassType] : 0);
>>
>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>>  286       (Metaspace::using_class_space() ?
>>  287         _allocated_used_words[Metaspace::ClassType] : 0);
>>
>> universe.cpp:
>>
>>  849   assert((intptr_t)Universe::narrow_oop_base() <=
>> (intptr_t)(Universe::heap()->base() -
>>  850     os::vm_page_size()) ||
>>  851            Universe::narrow_oop_base() == NULL, "invalid value");
>>
>>
>> Thanks,
>> Vladimir
>>
>> On 8/2/13 1:31 PM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this updated webrev for bug 8003424:
>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>
>>> The updated webrev has a lot of changes from the previous webrev,
>>> including the following:
>>>
>>>     1. Class metaspace information is now output when
>>>     -XX:+PrintCompressedOopsMode is specified.
>>>
>>>     2. decode_klass_not_null(Register dst, Register src) no longer
>>>     clobbers R12.
>>>
>>>     3. Method using_class_vsm() was renamed to using_class_space().
>>>
>>>     4. Type narrowKlass was added and replaces narrowOop, where
>>> appropriate.
>>>
>>>     5. The Metaspace:: qualifier was removed, where it was unnecessary.
>>>
>>>     6. Metaspace::initialize_class_space() was made private.
>>>
>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>>> updated.
>>>
>>> Performance tests were run by Jenny using specjvm2008, specjbb2005, and
>>> specjbb2013.  The results showed no significant performance difference
>>> in terms of scores and gc behavior.
>>>
>>> Additional testing was done on Solaris Sparc and Linux x86 using
>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>>
>>> Please let me know what additional tests should be run.
>>>
>>> Thanks!
>>> Harold
>>>
>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>> Hi Harold,
>>>>
>>>> > Usually the narrow_klass_base will be 32G and the
>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>>>> that
>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>> unless
>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that make
>>>> sense?
>>>>
>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000 and I
>>>> am tempted to use may be bts (bit set) to avoid R12 usage (assuming or
>>>> with check that class metaspace size < 32Gb).
>>>>
>>>> > Is there one prefix byte per instruction, or just for certain
>>>> instructions?
>>>>
>>>> "Not all instructions require a REX prefix in 64-bit mode. A prefix is
>>>> necessary only if an instruction references one of the extended
>>>> registers or uses a 64-bit operand."
>>>>
>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and =32
>>>> and big java heap. Recently we got several bugs which indicated that
>>>> we did not separate cleanly oops and klass pointers en/decoding.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>> Hi Vladimir,
>>>>>
>>>>> Thank you for the review!  Please see inline comments.
>>>>>
>>>>> Thanks, Harold
>>>>>
>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>>> Nice clean up, Harold
>>>>>>>
>>>>>>> Could you add the size of class metaspace in output with
>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>>>>> remember an
>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>>> Will be done in next webrev.
>>>>>>>
>>>>>>> Also it would be nice to print these info line (and compressed oops
>>>>>>> info
>>>>>>> line) in hs_err files.
>>>>> I filed an enhancement bug for this: 8021264
>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>>
>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>>>>>>> x86_64.ad.
>>>>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also note
>>>>>>> that code in .ad file does not check the encoding mode for narrow
>>>>>>> klass/oop so it should be conservative and assume that arithmetic
>>>>>>> instructions are used.
>>>>> OK. Thanks.
>>>>>>>
>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>>>>>>> 4Gb so
>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>>> encoding/decoding without destroying R12.
>>>>>>
>>>>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>>> But the base will normally be 32Gb.  So this case won't happen very
>>>>> often.
>>>>>>
>>>>>> You definitely should not use R12 in decode_klass_not_null(Register
>>>>>> dst, Register src) method where you have free 'dst' register.
>>>>> Will be fixed in next webrev.
>>>>>>
>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>>
>>>>>> decode:
>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>>   }
>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>> }
>>>>>>
>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>>>>> (max positive int).
>>>>> Usually the narrow_klass_base will be 32G and the
>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>>>>> that
>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>> unless
>>>>> we do multiple addq(r, narrow_klass_base_shifted()).  Does that make
>>>>> sense?
>>>>>>
>>>>>> And you have general memory reservation problem. At least on Solaris,
>>>>>> as I remember, OS will always try to keep protected 4Kb pages between
>>>>>> different requested memory regions. That is why in jdk7 we first
>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>>> compressed oops.
>>>>>>
>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>>>> compressed
>>>>>> oops and with Xmx20Gb.
>>>>> I verifed that we get either cds_address+cds_total as the address, or
>>>>> CompressedKlassPointersBase as the address without CDS on Linux,
>>>>> Windows
>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap sizes and
>>>>> -Xmx32G.
>>>>>
>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the
>>>>> desired
>>>>> CDS address for class metaspace regardless of heap size.
>>>>>>
>>>>>>>
>>>>>>> instr_size_for_decode_klass_not_null() is ugly but unfortunately we
>>>>>>> can't do other way. I assume you use max size because depending on
>>>>>>> registers used in instructions you will or will not get prefix byte
>>>>>>> (r8-r15).
>>>>> Is there one prefix byte per instruction, or just for certain
>>>>> instructions?
>>>>>>>
>>>>>>> I will look on changes in more details may be late.
>>>>>>
>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>>>>> which are not obvious.
>>>>> I changed using_class_vsm() to using_class_space().
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review this fix for bug 8003424.
>>>>>>>>
>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>>> Open bug links at:
>>>>>>>>
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>>
>>>>>>>> JBS Bug links at
>>>>>>>>
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>>
>>>>>>>>
>>>>>>>> This fix provides support for using compressed klass pointers with
>>>>>>>> CDS.
>>>>>>>> It also changes the class metaspace allocation on 64-bit platforms
>>>>>>>> when
>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the
>>>>>>>> class
>>>>>>>> metaspace as part of the Java Heap allocation and locating it at
>>>>>>>> the
>>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>>> separately,
>>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>>> metaspace
>>>>>>>> because it won't be backed up against the Java heap. If CDS is
>>>>>>>> being
>>>>>>>> used, then the CDS region will be allocated between the Java
>>>>>>>> heap and
>>>>>>>> the metaspace.
>>>>>>>>
>>>>>>>> The new class metaspace allocation code tries to allocate memory at
>>>>>>>> 32G,
>>>>>>>> or above the CDS region, if it is present.  Because of this,
>>>>>>>> encoding
>>>>>>>> and decoding of compressed klass pointers will always require use
>>>>>>>> of a
>>>>>>>> base register.  So, encoding and decoding of compressed klass
>>>>>>>> pointers
>>>>>>>> will differ from compressed oops.
>>>>>>>>
>>>>>>>> There are no class metaspace allocation changes if
>>>>>>>> UseCompressedKlassPointers is turned off or if running on a 32-bit
>>>>>>>> platform.
>>>>>>>>
>>>>>>>> The code changes also include some cleanup and will fix bugs
>>>>>>>> 8016729,
>>>>>>>> 8011610, and 8003424.
>>>>>>>>
>>>>>>>>
>>>>>>>> Many of the modules in this webrev contain a lot of changes.
>>>>>>>> Modules
>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were changed to
>>>>>>>> support the new encoding and decoding of compressed klass pointers.
>>>>>>>>
>>>>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>>>>> allocation for metaspace and the CDS region and to determine
>>>>>>>> compressed
>>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>>
>>>>>>>> Most of the changes to module universe.cpp were to remove code
>>>>>>>> related
>>>>>>>> to allocating metaspace and remove code that considered compressed
>>>>>>>> klass
>>>>>>>> pointers when determining the compressed oops compression
>>>>>>>> mechanism.
>>>>>>>>
>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as part
>>>>>>>> of a
>>>>>>>> cleanup requested by Coleen.
>>>>>>>>
>>>>>>>>
>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg tests,
>>>>>>>> JPRT,
>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>>>>> tests.  Most of the test were run with -Xshare:on and -Xshare:off
>>>>>>>> (with
>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>>>>> 64-Bit
>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests
>>>>>>>> were
>>>>>>>> run on Solaris x86.
>>>>>>>>
>>>>>>>> The performance impact of these changes is TBD.
>>>>>>>>
>>>>>>>> Thanks, Harold
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>

From mikael.vidstedt at oracle.com  Thu Aug  8 15:25:05 2013
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 08 Aug 2013 15:25:05 -0700
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <52028A69.8010207@oracle.com>
References: <5201886C.1030206@oracle.com> <52024E1A.4000908@oracle.com>
	<520275B8.5010101@oracle.com> <52028A69.8010207@oracle.com>
Message-ID: <52041AC1.4000803@oracle.com>


Coleen,

After having tried numerous different versions I ended up with this:

http://cr.openjdk.java.net/~mikael/webrevs/8022452.3/webrev

Summary of the changes:

* The GetNativeSystemInfo call has been moved up before the switch, but 
is only called if the os version is recent enough, and  we actually care 
about the si.wProcessorArchitecture field.

* The true/else branches in the if-diamond have been switch to avoid the 
negation of the condition.

* While at it I added support for recognizing "Windows Server 2008 R2" 
(6.1 non-workstation) which we apparently haven't recognized earlier, 
but which is something the JDK code recognizes [1].

* The " , 64 bit" has been move out below the switch, but is only 
relevant/tested for on recent enough Windows versions, just like the old 
code did.

Feedback much appreciated! I'm also investigating if it would be 
possible to unify/share the code with the java_props_md.c logic [1] to 
avoid the duplication, but for now this may have to do. In addition to 
that the code can be cleaned up further if we only support VS2010+, 
which I believe is de facto since JDK 7 anyway; I will investigate that 
as a separate improvement.

Thanks,
Mikael

[1] 
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/e057cddf0d6c/src/windows/native/java/lang/java_props_md.c 
(line 451).

On 2013-08-07 10:56, Coleen Phillimore wrote:
>
> Mikael,
>
> I do like your new version better but because you changed so much, it 
> should be verified on all versions of windows.   Which you might not 
> want to do.   My suggestion to make this code nicer (fix case stmt and 
> outline common code) was really simple and I think can be verified by 
> code inspection, which might be less work and easier to review.
>
> Coleen
>
> On 8/7/2013 12:28 PM, Mikael Vidstedt wrote:
>>
>> Coleen,
>>
>> Funny you should mention that, and since I fully agree with you I 
>> actually did prepare another version of the patch which is heavily 
>> inspired by the java_props_md.c implementation:
>>
>> http://cr.openjdk.java.net/~mikael/webrevs/winvercleanup2/webrev/
>>
>> I personally like this version better, but the one thing that held me 
>> back was the fact that I will basically want to dig up machines with 
>> all the different (supported) Windows versions and verify that the 
>> code is still correct in all cases. If you think this is the way to 
>> go I more than willing to will do so. Let me know what you think 
>> about the new version of the patch!
>>
>> There's no real urgency here - I'd rather do it correct once than...
>>
>> Cheers,
>> Mikael
>>
>>
>> On 2013-08-07 06:39, Coleen Phillimore wrote:
>>>
>>> It looks like the code under the case for all these releases, should 
>>> be different case statements for each, rather than these cascading 
>>> 'if' statements.  And make 1668-1673 a new function returning si.   
>>> So if we have a new release, in general it will work because the 
>>> default will print out something.   But a better default would be 
>>> lines 1712-1717 which are dead code now.
>>>
>>> Sorry, I know it's simple and urgent but this seems to be getting 
>>> increasingly ugly.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>>>>
>>>> Please review the following change:
>>>>
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>>>>
>>>> The patch adds support to os_windows.cpp for recognizing the 
>>>> upcoming Windows versions: Windows 8.1 and Windows Server 2012 R2.
>>>>
>>>> The changed is based on the corresponding code on the JDK 
>>>> side[1][2][3].
>>>>
>>>> Thanks,
>>>> Mikael
>>>>
>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
>>>> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
>>>> [3] 
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Thu Aug  8 15:34:24 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 08 Aug 2013 18:34:24 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <52040F88.9070406@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
	<52002E68.6080901@oracle.com> <5202691E.6020500@oracle.com>
	<52040F88.9070406@oracle.com>
Message-ID: <52041CF0.4000801@oracle.com>


Hi Vladimir,

I have a couple of answers and I'll let Harold answer the rest.

On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
> On 8/7/13 8:34 AM, harold seigel wrote:
>> Hi Vladimir,
>>
>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>> Harold,
>>>
>>> Note, on SPARC set() could generate up to 8 instructions to load
>>> 64-bit constant into register. So I am not sure that it will be faster
>>> than load.
>> We thought it would be faster because it doesn't need to load anything
>> from memory.
>
> For good value (0x800000000) it should use only 2-3 instructions.
> I think you can keep using set().
>
>>>
>>> I can't find where in CDS you store information about compressed klass
>>> pointers and compressed oops parameters which were used during dump?
>>> How you verify that correct parameters/flags are ussed when such CDS
>>> is used later?
>> No compressed klass pointers nor compressed oops get written to the
>> archive.  So, the compressed klass pointers and compressed oops
>> parameters do not need to be recorded in the archive.
>
> So you are saying that all klass pointers (references to klasses) in 
> metadata structures in metaspace are full. 

Yes, they are.  (methodOops weren't in the InstanceKlass::_methods array 
with Permgen but they are uncompressed now).

> And klass pointers are only compressed in java object headers (which 
> are not part of CDS). Right?

The InstanceKlass has offsets to fields in the instance, and they depend 
on both compressed oops and compressed klass pointers.   So both have to 
be on for the offsets to be valid.

But the base and compressed values are not stored anywhere in the CDS 
archive.

> And you don't care about UseCompressedOops and 
> UseCompressedKlassPointers flags settings when you dump it into 
> archive. The only limit is:
>
> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total
>
> Then I don't understand why you can't use/load CDS archive when coop 
> or compklass are off:
>
> > If coop is turned off then CDS cannot be used.  CDS will only be
> > supported if both UseCompressedOops and UseCompressedKlassPointers are
> > TRUE.
>
> Also based on code in arguments.cpp it is allowed to specify 
> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command line:
>
> 1466     // Turn on UseCompressedKlassPointers too
> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
> 1469     }
>
> Did you tested such combination?

I should let Harold answer this but I believe this is what his test 
does.  For CDS on 64 bit, both must be on.   We didn't want to create 4 
different archives.   And it wouldn't make too much sense since CDS for 
64 bit is a footprint savings so why would you use it without 
compressing oops and class pointers?  It's not a startup savings on 
server because we turn off interpreter bytecode quickening.

Coleen

>
>>>
>>> set_narrow_klass_base_and_shift() and
>>> can_use_cds_with_metaspace_addr() have the same code for
>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>> can_use_cds_with_metaspace_addr() from
>>> set_narrow_klass_base_and_shift() ?
>> I could add new inlined methods that determine the higher_address and
>> lower_base when UseSharedSpaces is true and have them called from
>> set_narrow_klass_base_and_shift() and
>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>
> I tried several approaches but your implementation is more clean. So I 
> agree to keep what you have now.
>
>
> Also I found strange assert which should always fail (old code in 
> global_initialize() in metaspace.cpp):
>
> 2959     if (UseSharedSpaces) {
> ...
> 2969       } else {
> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
> 2971                "archive file not closed or shared spaces not 
> disabled.");
>
> Thanks,
> Vladimir
>
>>>
>>> I see that you unconditionally set comp klass ptr base and shift for
>>> DumpSharedSpaces. Should you do the check similar to
>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>>> don't even check UseCompressedKlassPointers.
>> I don't think the checks are needed because the information written to
>> the archive is not affected by the size of the class metaspace.
>>
>> Also, I recently added code to arguments.cpp that will generate an error
>> if UseCompressedOops or UseCompressedKlassPointers is turned off and
>> DumpSharedSpaces is on.
>>>
>>> Why you have next limitation? What if coop can't be used because of
>>> big heap?:
>>>
>>> +     // UseCompressedOops and UseCompressedKlassPointers must be on
>>> for UseSharedSpaces.
>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>> +       no_shared_spaces();
>> If coop is turned off then CDS cannot be used.  CDS will only be
>> supported if both UseCompressedOops and UseCompressedKlassPointers are
>> TRUE.
>>>
>>> Could you move UseCompressedKlassPointers code in arguments.cpp into
>>> separate method similar to set_use_compressed_oops()?
>> Done.
>>>
>>> About new tests.
>>> The first test in CDSCompressedKPtrsError misses
>>> -XX:+UseCompressedOops flag.
>> Fixed.
>>>
>>> Could you also test cross flags combinations?:
>>>
>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>> Done.
>>>
>>> It would be nice to have test to check ClassMetaspaceSize value range.
>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint
>>> or maxuint.
>> A member of our runtime SQE group is writing additional tests. I'll ask
>> him to write a ClassMetaspaceSize range test.
>>
>> We chose 3Gb because we thought it was a sufficiently large size.
>>>
>>>
>>> About code style, indention. We align next line to corresponding part
>>> of previous line if we need to split a line. And sometimes it is
>>> better to keep one long line. I understand some of them were before
>>> your changes but, please, clean up at lest ones you touched.
>> Done.
>>>
>>> Cases in metaspace.cpp:
>>>
>>> 2263   assert(raw_word_size >= min_size,
>>> 2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<"
>>> SIZE_FORMAT, word_size, min_size));
>>>
>>>
>>> 2485   if (Metaspace::using_class_space() &&
>>> 2486     (Metaspace::class_space_list() != NULL)) {
>>>
>>>
>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>> 2575                       (Metaspace::using_class_space() ?
>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>
>>>
>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>> SIZE_FORMAT ", "
>>> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT 
>>> ", "
>>> 2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>> ", "
>>> 2697                            "large count " SIZE_FORMAT,
>>> 2698              cls_specialized_count, cls_specialized_waste,
>>> 2699              cls_small_count, cls_small_waste,
>>> 2700              cls_medium_count, cls_medium_waste,
>>> cls_humongous_count);
>>>
>>>
>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G > addr) &&
>>> 2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>
>>>
>>> 2889         vm_exit_during_initialization(err_msg(
>>> 2890           "Could not allocate metaspace: %d bytes",
>>> 2891           class_metaspace_size()));
>>>
>>>
>>> 3107     return using_class_space() ?
>>> 3108       class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>
>>>
>>> 3157     if (is_class && using_class_space()) {
>>> 3158        class_vsm()->deallocate(ptr, word_size);
>>>
>>>
>>> 3305   return space_list()->contains(ptr) ||
>>> 3306     (using_class_space() && class_space_list()->contains(ptr));
>>>
>>> metaspace.hpp:
>>>
>>>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
>>>  271       (Metaspace::using_class_space() ?
>>>  272         _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>
>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>>>  286       (Metaspace::using_class_space() ?
>>>  287         _allocated_used_words[Metaspace::ClassType] : 0);
>>>
>>> universe.cpp:
>>>
>>>  849   assert((intptr_t)Universe::narrow_oop_base() <=
>>> (intptr_t)(Universe::heap()->base() -
>>>  850     os::vm_page_size()) ||
>>>  851            Universe::narrow_oop_base() == NULL, "invalid value");
>>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>> Hi,
>>>>
>>>> Please review this updated webrev for bug 8003424:
>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>
>>>> The updated webrev has a lot of changes from the previous webrev,
>>>> including the following:
>>>>
>>>>     1. Class metaspace information is now output when
>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>>
>>>>     2. decode_klass_not_null(Register dst, Register src) no longer
>>>>     clobbers R12.
>>>>
>>>>     3. Method using_class_vsm() was renamed to using_class_space().
>>>>
>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>>>> appropriate.
>>>>
>>>>     5. The Metaspace:: qualifier was removed, where it was 
>>>> unnecessary.
>>>>
>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>
>>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>>>> updated.
>>>>
>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005, 
>>>> and
>>>> specjbb2013.  The results showed no significant performance difference
>>>> in terms of scores and gc behavior.
>>>>
>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>>>
>>>> Please let me know what additional tests should be run.
>>>>
>>>> Thanks!
>>>> Harold
>>>>
>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>> Hi Harold,
>>>>>
>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>>>>> that
>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>> unless
>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that make
>>>>> sense?
>>>>>
>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000 
>>>>> and I
>>>>> am tempted to use may be bts (bit set) to avoid R12 usage 
>>>>> (assuming or
>>>>> with check that class metaspace size < 32Gb).
>>>>>
>>>>> > Is there one prefix byte per instruction, or just for certain
>>>>> instructions?
>>>>>
>>>>> "Not all instructions require a REX prefix in 64-bit mode. A 
>>>>> prefix is
>>>>> necessary only if an instruction references one of the extended
>>>>> registers or uses a 64-bit operand."
>>>>>
>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and =32
>>>>> and big java heap. Recently we got several bugs which indicated that
>>>>> we did not separate cleanly oops and klass pointers en/decoding.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>>> Hi Vladimir,
>>>>>>
>>>>>> Thank you for the review!  Please see inline comments.
>>>>>>
>>>>>> Thanks, Harold
>>>>>>
>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>>>> Nice clean up, Harold
>>>>>>>>
>>>>>>>> Could you add the size of class metaspace in output with
>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>>>>>> remember an
>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>>>> Will be done in next webrev.
>>>>>>>>
>>>>>>>> Also it would be nice to print these info line (and compressed 
>>>>>>>> oops
>>>>>>>> info
>>>>>>>> line) in hs_err files.
>>>>>> I filed an enhancement bug for this: 8021264
>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>>>
>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>>>>>>>> x86_64.ad.
>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also 
>>>>>>>> note
>>>>>>>> that code in .ad file does not check the encoding mode for narrow
>>>>>>>> klass/oop so it should be conservative and assume that arithmetic
>>>>>>>> instructions are used.
>>>>>> OK. Thanks.
>>>>>>>>
>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>>>>>>>> 4Gb so
>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>>>> encoding/decoding without destroying R12.
>>>>>>>
>>>>>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>>>> But the base will normally be 32Gb.  So this case won't happen very
>>>>>> often.
>>>>>>>
>>>>>>> You definitely should not use R12 in decode_klass_not_null(Register
>>>>>>> dst, Register src) method where you have free 'dst' register.
>>>>>> Will be fixed in next webrev.
>>>>>>>
>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>>>
>>>>>>> decode:
>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>>>   }
>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>>> }
>>>>>>>
>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>>>>>> (max positive int).
>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>>>>>> that
>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>>> unless
>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that make
>>>>>> sense?
>>>>>>>
>>>>>>> And you have general memory reservation problem. At least on 
>>>>>>> Solaris,
>>>>>>> as I remember, OS will always try to keep protected 4Kb pages 
>>>>>>> between
>>>>>>> different requested memory regions. That is why in jdk7 we first
>>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>>>> compressed oops.
>>>>>>>
>>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>>>>> compressed
>>>>>>> oops and with Xmx20Gb.
>>>>>> I verifed that we get either cds_address+cds_total as the 
>>>>>> address, or
>>>>>> CompressedKlassPointersBase as the address without CDS on Linux,
>>>>>> Windows
>>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap 
>>>>>> sizes and
>>>>>> -Xmx32G.
>>>>>>
>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the
>>>>>> desired
>>>>>> CDS address for class metaspace regardless of heap size.
>>>>>>>
>>>>>>>>
>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but 
>>>>>>>> unfortunately we
>>>>>>>> can't do other way. I assume you use max size because depending on
>>>>>>>> registers used in instructions you will or will not get prefix 
>>>>>>>> byte
>>>>>>>> (r8-r15).
>>>>>> Is there one prefix byte per instruction, or just for certain
>>>>>> instructions?
>>>>>>>>
>>>>>>>> I will look on changes in more details may be late.
>>>>>>>
>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>>>>>> which are not obvious.
>>>>>> I changed using_class_vsm() to using_class_space().
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review this fix for bug 8003424.
>>>>>>>>>
>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>>>> Open bug links at:
>>>>>>>>>
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>>>
>>>>>>>>> JBS Bug links at
>>>>>>>>>
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This fix provides support for using compressed klass pointers 
>>>>>>>>> with
>>>>>>>>> CDS.
>>>>>>>>> It also changes the class metaspace allocation on 64-bit 
>>>>>>>>> platforms
>>>>>>>>> when
>>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the
>>>>>>>>> class
>>>>>>>>> metaspace as part of the Java Heap allocation and locating it at
>>>>>>>>> the
>>>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>>>> separately,
>>>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>>>> metaspace
>>>>>>>>> because it won't be backed up against the Java heap. If CDS is
>>>>>>>>> being
>>>>>>>>> used, then the CDS region will be allocated between the Java
>>>>>>>>> heap and
>>>>>>>>> the metaspace.
>>>>>>>>>
>>>>>>>>> The new class metaspace allocation code tries to allocate 
>>>>>>>>> memory at
>>>>>>>>> 32G,
>>>>>>>>> or above the CDS region, if it is present. Because of this,
>>>>>>>>> encoding
>>>>>>>>> and decoding of compressed klass pointers will always require use
>>>>>>>>> of a
>>>>>>>>> base register.  So, encoding and decoding of compressed klass
>>>>>>>>> pointers
>>>>>>>>> will differ from compressed oops.
>>>>>>>>>
>>>>>>>>> There are no class metaspace allocation changes if
>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a 
>>>>>>>>> 32-bit
>>>>>>>>> platform.
>>>>>>>>>
>>>>>>>>> The code changes also include some cleanup and will fix bugs
>>>>>>>>> 8016729,
>>>>>>>>> 8011610, and 8003424.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Many of the modules in this webrev contain a lot of changes.
>>>>>>>>> Modules
>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were 
>>>>>>>>> changed to
>>>>>>>>> support the new encoding and decoding of compressed klass 
>>>>>>>>> pointers.
>>>>>>>>>
>>>>>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>>>>>> allocation for metaspace and the CDS region and to determine
>>>>>>>>> compressed
>>>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>>>
>>>>>>>>> Most of the changes to module universe.cpp were to remove code
>>>>>>>>> related
>>>>>>>>> to allocating metaspace and remove code that considered 
>>>>>>>>> compressed
>>>>>>>>> klass
>>>>>>>>> pointers when determining the compressed oops compression
>>>>>>>>> mechanism.
>>>>>>>>>
>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as part
>>>>>>>>> of a
>>>>>>>>> cleanup requested by Coleen.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg 
>>>>>>>>> tests,
>>>>>>>>> JPRT,
>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>>>>>> tests.  Most of the test were run with -Xshare:on and -Xshare:off
>>>>>>>>> (with
>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>>>>>> 64-Bit
>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests
>>>>>>>>> were
>>>>>>>>> run on Solaris x86.
>>>>>>>>>
>>>>>>>>> The performance impact of these changes is TBD.
>>>>>>>>>
>>>>>>>>> Thanks, Harold
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>


From vladimir.kozlov at oracle.com  Thu Aug  8 15:55:02 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 08 Aug 2013 15:55:02 -0700
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <52041CF0.4000801@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
	<52002E68.6080901@oracle.com> <5202691E.6020500@oracle.com>
	<52040F88.9070406@oracle.com> <52041CF0.4000801@oracle.com>
Message-ID: <520421C6.8050609@oracle.com>

Coleen, Harold

 > The InstanceKlass has offsets to fields in the instance, and they depend
 > on both compressed oops and compressed klass pointers.   So both have to
 > be on for the offsets to be valid.

So there is dependency on UseCompressedOops and
UseCompressedKlassPointers flags during dump.

Then why the check is done only for UseSharedSpaces and not for 
DumpSharedSpaces?:

     if (DumpSharedSpaces) {
       if (RequireSharedSpaces) {
         warning("cannot dump shared archive while using shared archive");
       }
       UseSharedSpaces = false;
+ #ifdef _LP64
+   } else {
+     // UseCompressedOops and UseCompressedKlassPointers must be on for 
UseSharedSpaces.
+     if (!UseCompressedOops || !UseCompressedKlassPointers) {
+       no_shared_spaces();
+     }
+ #endif
     }

Thanks,
Vladimir

On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>
> Hi Vladimir,
>
> I have a couple of answers and I'll let Harold answer the rest.
>
> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>> On 8/7/13 8:34 AM, harold seigel wrote:
>>> Hi Vladimir,
>>>
>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>>> Harold,
>>>>
>>>> Note, on SPARC set() could generate up to 8 instructions to load
>>>> 64-bit constant into register. So I am not sure that it will be faster
>>>> than load.
>>> We thought it would be faster because it doesn't need to load anything
>>> from memory.
>>
>> For good value (0x800000000) it should use only 2-3 instructions.
>> I think you can keep using set().
>>
>>>>
>>>> I can't find where in CDS you store information about compressed klass
>>>> pointers and compressed oops parameters which were used during dump?
>>>> How you verify that correct parameters/flags are ussed when such CDS
>>>> is used later?
>>> No compressed klass pointers nor compressed oops get written to the
>>> archive.  So, the compressed klass pointers and compressed oops
>>> parameters do not need to be recorded in the archive.
>>
>> So you are saying that all klass pointers (references to klasses) in
>> metadata structures in metaspace are full.
>
> Yes, they are.  (methodOops weren't in the InstanceKlass::_methods array
> with Permgen but they are uncompressed now).
>
>> And klass pointers are only compressed in java object headers (which
>> are not part of CDS). Right?
>
> The InstanceKlass has offsets to fields in the instance, and they depend
> on both compressed oops and compressed klass pointers.   So both have to
> be on for the offsets to be valid.
>
> But the base and compressed values are not stored anywhere in the CDS
> archive.
>
>> And you don't care about UseCompressedOops and
>> UseCompressedKlassPointers flags settings when you dump it into
>> archive. The only limit is:
>>
>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total
>>
>> Then I don't understand why you can't use/load CDS archive when coop
>> or compklass are off:
>>
>> > If coop is turned off then CDS cannot be used.  CDS will only be
>> > supported if both UseCompressedOops and UseCompressedKlassPointers are
>> > TRUE.
>>
>> Also based on code in arguments.cpp it is allowed to specify
>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command line:
>>
>> 1466     // Turn on UseCompressedKlassPointers too
>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>> 1469     }
>>
>> Did you tested such combination?
>
> I should let Harold answer this but I believe this is what his test
> does.  For CDS on 64 bit, both must be on.   We didn't want to create 4
> different archives.   And it wouldn't make too much sense since CDS for
> 64 bit is a footprint savings so why would you use it without
> compressing oops and class pointers?  It's not a startup savings on
> server because we turn off interpreter bytecode quickening.
>
> Coleen
>
>>
>>>>
>>>> set_narrow_klass_base_and_shift() and
>>>> can_use_cds_with_metaspace_addr() have the same code for
>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>>> can_use_cds_with_metaspace_addr() from
>>>> set_narrow_klass_base_and_shift() ?
>>> I could add new inlined methods that determine the higher_address and
>>> lower_base when UseSharedSpaces is true and have them called from
>>> set_narrow_klass_base_and_shift() and
>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>>
>> I tried several approaches but your implementation is more clean. So I
>> agree to keep what you have now.
>>
>>
>> Also I found strange assert which should always fail (old code in
>> global_initialize() in metaspace.cpp):
>>
>> 2959     if (UseSharedSpaces) {
>> ...
>> 2969       } else {
>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>> 2971                "archive file not closed or shared spaces not
>> disabled.");
>>
>> Thanks,
>> Vladimir
>>
>>>>
>>>> I see that you unconditionally set comp klass ptr base and shift for
>>>> DumpSharedSpaces. Should you do the check similar to
>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>>>> don't even check UseCompressedKlassPointers.
>>> I don't think the checks are needed because the information written to
>>> the archive is not affected by the size of the class metaspace.
>>>
>>> Also, I recently added code to arguments.cpp that will generate an error
>>> if UseCompressedOops or UseCompressedKlassPointers is turned off and
>>> DumpSharedSpaces is on.
>>>>
>>>> Why you have next limitation? What if coop can't be used because of
>>>> big heap?:
>>>>
>>>> +     // UseCompressedOops and UseCompressedKlassPointers must be on
>>>> for UseSharedSpaces.
>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>> +       no_shared_spaces();
>>> If coop is turned off then CDS cannot be used.  CDS will only be
>>> supported if both UseCompressedOops and UseCompressedKlassPointers are
>>> TRUE.
>>>>
>>>> Could you move UseCompressedKlassPointers code in arguments.cpp into
>>>> separate method similar to set_use_compressed_oops()?
>>> Done.
>>>>
>>>> About new tests.
>>>> The first test in CDSCompressedKPtrsError misses
>>>> -XX:+UseCompressedOops flag.
>>> Fixed.
>>>>
>>>> Could you also test cross flags combinations?:
>>>>
>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>> Done.
>>>>
>>>> It would be nice to have test to check ClassMetaspaceSize value range.
>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint
>>>> or maxuint.
>>> A member of our runtime SQE group is writing additional tests. I'll ask
>>> him to write a ClassMetaspaceSize range test.
>>>
>>> We chose 3Gb because we thought it was a sufficiently large size.
>>>>
>>>>
>>>> About code style, indention. We align next line to corresponding part
>>>> of previous line if we need to split a line. And sometimes it is
>>>> better to keep one long line. I understand some of them were before
>>>> your changes but, please, clean up at lest ones you touched.
>>> Done.
>>>>
>>>> Cases in metaspace.cpp:
>>>>
>>>> 2263   assert(raw_word_size >= min_size,
>>>> 2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<"
>>>> SIZE_FORMAT, word_size, min_size));
>>>>
>>>>
>>>> 2485   if (Metaspace::using_class_space() &&
>>>> 2486     (Metaspace::class_space_list() != NULL)) {
>>>>
>>>>
>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>>> 2575                       (Metaspace::using_class_space() ?
>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>>
>>>>
>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>>> SIZE_FORMAT ", "
>>>> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT
>>>> ", "
>>>> 2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>>> ", "
>>>> 2697                            "large count " SIZE_FORMAT,
>>>> 2698              cls_specialized_count, cls_specialized_waste,
>>>> 2699              cls_small_count, cls_small_waste,
>>>> 2700              cls_medium_count, cls_medium_waste,
>>>> cls_humongous_count);
>>>>
>>>>
>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G > addr) &&
>>>> 2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>>
>>>>
>>>> 2889         vm_exit_during_initialization(err_msg(
>>>> 2890           "Could not allocate metaspace: %d bytes",
>>>> 2891           class_metaspace_size()));
>>>>
>>>>
>>>> 3107     return using_class_space() ?
>>>> 3108       class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>>
>>>>
>>>> 3157     if (is_class && using_class_space()) {
>>>> 3158        class_vsm()->deallocate(ptr, word_size);
>>>>
>>>>
>>>> 3305   return space_list()->contains(ptr) ||
>>>> 3306     (using_class_space() && class_space_list()->contains(ptr));
>>>>
>>>> metaspace.hpp:
>>>>
>>>>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
>>>>  271       (Metaspace::using_class_space() ?
>>>>  272         _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>>
>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>>>>  286       (Metaspace::using_class_space() ?
>>>>  287         _allocated_used_words[Metaspace::ClassType] : 0);
>>>>
>>>> universe.cpp:
>>>>
>>>>  849   assert((intptr_t)Universe::narrow_oop_base() <=
>>>> (intptr_t)(Universe::heap()->base() -
>>>>  850     os::vm_page_size()) ||
>>>>  851            Universe::narrow_oop_base() == NULL, "invalid value");
>>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this updated webrev for bug 8003424:
>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>>
>>>>> The updated webrev has a lot of changes from the previous webrev,
>>>>> including the following:
>>>>>
>>>>>     1. Class metaspace information is now output when
>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>>>
>>>>>     2. decode_klass_not_null(Register dst, Register src) no longer
>>>>>     clobbers R12.
>>>>>
>>>>>     3. Method using_class_vsm() was renamed to using_class_space().
>>>>>
>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>>>>> appropriate.
>>>>>
>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>>>> unnecessary.
>>>>>
>>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>>
>>>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>>>>> updated.
>>>>>
>>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005,
>>>>> and
>>>>> specjbb2013.  The results showed no significant performance difference
>>>>> in terms of scores and gc behavior.
>>>>>
>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>>>>
>>>>> Please let me know what additional tests should be run.
>>>>>
>>>>> Thanks!
>>>>> Harold
>>>>>
>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>>> Hi Harold,
>>>>>>
>>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>>>>>> that
>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>>> unless
>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that make
>>>>>> sense?
>>>>>>
>>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000
>>>>>> and I
>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>>>>> (assuming or
>>>>>> with check that class metaspace size < 32Gb).
>>>>>>
>>>>>> > Is there one prefix byte per instruction, or just for certain
>>>>>> instructions?
>>>>>>
>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>>>>> prefix is
>>>>>> necessary only if an instruction references one of the extended
>>>>>> registers or uses a 64-bit operand."
>>>>>>
>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and =32
>>>>>> and big java heap. Recently we got several bugs which indicated that
>>>>>> we did not separate cleanly oops and klass pointers en/decoding.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>>>> Hi Vladimir,
>>>>>>>
>>>>>>> Thank you for the review!  Please see inline comments.
>>>>>>>
>>>>>>> Thanks, Harold
>>>>>>>
>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>>>>> Nice clean up, Harold
>>>>>>>>>
>>>>>>>>> Could you add the size of class metaspace in output with
>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>>>>>>> remember an
>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>>>>> Will be done in next webrev.
>>>>>>>>>
>>>>>>>>> Also it would be nice to print these info line (and compressed
>>>>>>>>> oops
>>>>>>>>> info
>>>>>>>>> line) in hs_err files.
>>>>>>> I filed an enhancement bug for this: 8021264
>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>>>>
>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>>>>>>>>> x86_64.ad.
>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use arithmetic
>>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also
>>>>>>>>> note
>>>>>>>>> that code in .ad file does not check the encoding mode for narrow
>>>>>>>>> klass/oop so it should be conservative and assume that arithmetic
>>>>>>>>> instructions are used.
>>>>>>> OK. Thanks.
>>>>>>>>>
>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>>>>>>>>> 4Gb so
>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>>>>> encoding/decoding without destroying R12.
>>>>>>>>
>>>>>>>> Correction. You can do it only if base < 2Gb max positive int (sign
>>>>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>>>>> But the base will normally be 32Gb.  So this case won't happen very
>>>>>>> often.
>>>>>>>>
>>>>>>>> You definitely should not use R12 in decode_klass_not_null(Register
>>>>>>>> dst, Register src) method where you have free 'dst' register.
>>>>>>> Will be fixed in next webrev.
>>>>>>>>
>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 64Gb.
>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>>>>
>>>>>>>> decode:
>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>>>>   }
>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= maxint
>>>>>>>> (max positive int).
>>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>>>>>>> that
>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>>>> unless
>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that make
>>>>>>> sense?
>>>>>>>>
>>>>>>>> And you have general memory reservation problem. At least on
>>>>>>>> Solaris,
>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
>>>>>>>> between
>>>>>>>> different requested memory regions. That is why in jdk7 we first
>>>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>>>>> compressed oops.
>>>>>>>>
>>>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>>>>>> compressed
>>>>>>>> oops and with Xmx20Gb.
>>>>>>> I verifed that we get either cds_address+cds_total as the
>>>>>>> address, or
>>>>>>> CompressedKlassPointersBase as the address without CDS on Linux,
>>>>>>> Windows
>>>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap
>>>>>>> sizes and
>>>>>>> -Xmx32G.
>>>>>>>
>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the
>>>>>>> desired
>>>>>>> CDS address for class metaspace regardless of heap size.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>>>>>>>> unfortunately we
>>>>>>>>> can't do other way. I assume you use max size because depending on
>>>>>>>>> registers used in instructions you will or will not get prefix
>>>>>>>>> byte
>>>>>>>>> (r8-r15).
>>>>>>> Is there one prefix byte per instruction, or just for certain
>>>>>>> instructions?
>>>>>>>>>
>>>>>>>>> I will look on changes in more details may be late.
>>>>>>>>
>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use abbreviations
>>>>>>>> which are not obvious.
>>>>>>> I changed using_class_vsm() to using_class_space().
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please review this fix for bug 8003424.
>>>>>>>>>>
>>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>>>>> Open bug links at:
>>>>>>>>>>
>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>>>>
>>>>>>>>>> JBS Bug links at
>>>>>>>>>>
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This fix provides support for using compressed klass pointers
>>>>>>>>>> with
>>>>>>>>>> CDS.
>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>>>>>>>>> platforms
>>>>>>>>>> when
>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the
>>>>>>>>>> class
>>>>>>>>>> metaspace as part of the Java Heap allocation and locating it at
>>>>>>>>>> the
>>>>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>>>>> separately,
>>>>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>>>>> metaspace
>>>>>>>>>> because it won't be backed up against the Java heap. If CDS is
>>>>>>>>>> being
>>>>>>>>>> used, then the CDS region will be allocated between the Java
>>>>>>>>>> heap and
>>>>>>>>>> the metaspace.
>>>>>>>>>>
>>>>>>>>>> The new class metaspace allocation code tries to allocate
>>>>>>>>>> memory at
>>>>>>>>>> 32G,
>>>>>>>>>> or above the CDS region, if it is present. Because of this,
>>>>>>>>>> encoding
>>>>>>>>>> and decoding of compressed klass pointers will always require use
>>>>>>>>>> of a
>>>>>>>>>> base register.  So, encoding and decoding of compressed klass
>>>>>>>>>> pointers
>>>>>>>>>> will differ from compressed oops.
>>>>>>>>>>
>>>>>>>>>> There are no class metaspace allocation changes if
>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
>>>>>>>>>> 32-bit
>>>>>>>>>> platform.
>>>>>>>>>>
>>>>>>>>>> The code changes also include some cleanup and will fix bugs
>>>>>>>>>> 8016729,
>>>>>>>>>> 8011610, and 8003424.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Many of the modules in this webrev contain a lot of changes.
>>>>>>>>>> Modules
>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>>>>>>>>> changed to
>>>>>>>>>> support the new encoding and decoding of compressed klass
>>>>>>>>>> pointers.
>>>>>>>>>>
>>>>>>>>>> Module metaspace.cpp was changed significantly to support the new
>>>>>>>>>> allocation for metaspace and the CDS region and to determine
>>>>>>>>>> compressed
>>>>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>>>>
>>>>>>>>>> Most of the changes to module universe.cpp were to remove code
>>>>>>>>>> related
>>>>>>>>>> to allocating metaspace and remove code that considered
>>>>>>>>>> compressed
>>>>>>>>>> klass
>>>>>>>>>> pointers when determining the compressed oops compression
>>>>>>>>>> mechanism.
>>>>>>>>>>
>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as part
>>>>>>>>>> of a
>>>>>>>>>> cleanup requested by Coleen.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
>>>>>>>>>> tests,
>>>>>>>>>> JPRT,
>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and vm.mlvm.testlist
>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and -Xshare:off
>>>>>>>>>> (with
>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit Linux and
>>>>>>>>>> 64-Bit
>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests
>>>>>>>>>> were
>>>>>>>>>> run on Solaris x86.
>>>>>>>>>>
>>>>>>>>>> The performance impact of these changes is TBD.
>>>>>>>>>>
>>>>>>>>>> Thanks, Harold
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>
>

From serguei.spitsyn at oracle.com  Thu Aug  8 16:03:18 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 08 Aug 2013 16:03:18 -0700
Subject: RFR 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
In-Reply-To: <52016BBB.3040907@oracle.com>
References: <52016BBB.3040907@oracle.com>
Message-ID: <520423B6.3050009@oracle.com>

Coleen,

The fix looks good, I do not see any issues.

Thanks,
Serguei


On 8/6/13 2:33 PM, Coleen Phillimore wrote:
> Summary: ActiveMethodOopsCache was used to keep track of old versions 
> of some methods that are cached in Universe but is buggy with permgen 
> removal and not needed anymore
>
> There was a crash in this function that I couldn't reproduce.  It was 
> likely that the crash was for something else, but this is a lurking bug.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8009728/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009728
> local bug link https://jbs.oracle.com/bugs/browse/JDK-8009728
>
> Tested with vm.quick.testlist which includes redefine classes tests 
> and jck lang and vm tests.
>
> Thanks,
> Coleen


From coleen.phillimore at oracle.com  Thu Aug  8 16:01:27 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 08 Aug 2013 19:01:27 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <520421C6.8050609@oracle.com>
References: <51E82BC1.9010202@oracle.com> <51E86638.8040407@oracle.com>
	<51E9D23E.4080907@oracle.com> <51F01E6C.7060806@oracle.com>
	<51F03ABE.2090002@oracle.com> <51FC173B.6070205@oracle.com>
	<52002E68.6080901@oracle.com> <5202691E.6020500@oracle.com>
	<52040F88.9070406@oracle.com> <52041CF0.4000801@oracle.com>
	<520421C6.8050609@oracle.com>
Message-ID: <52042347.5040005@oracle.com>


Yes, there should be a check for that too.  Now I'll really let Harold 
answer.

Thanks,
Coleen

On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
> Coleen, Harold
>
> > The InstanceKlass has offsets to fields in the instance, and they 
> depend
> > on both compressed oops and compressed klass pointers.   So both 
> have to
> > be on for the offsets to be valid.
>
> So there is dependency on UseCompressedOops and
> UseCompressedKlassPointers flags during dump.
>
> Then why the check is done only for UseSharedSpaces and not for 
> DumpSharedSpaces?:
>
>     if (DumpSharedSpaces) {
>       if (RequireSharedSpaces) {
>         warning("cannot dump shared archive while using shared archive");
>       }
>       UseSharedSpaces = false;
> + #ifdef _LP64
> +   } else {
> +     // UseCompressedOops and UseCompressedKlassPointers must be on 
> for UseSharedSpaces.
> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
> +       no_shared_spaces();
> +     }
> + #endif
>     }
>
> Thanks,
> Vladimir
>
> On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>>
>> Hi Vladimir,
>>
>> I have a couple of answers and I'll let Harold answer the rest.
>>
>> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>>> On 8/7/13 8:34 AM, harold seigel wrote:
>>>> Hi Vladimir,
>>>>
>>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>>>> Harold,
>>>>>
>>>>> Note, on SPARC set() could generate up to 8 instructions to load
>>>>> 64-bit constant into register. So I am not sure that it will be 
>>>>> faster
>>>>> than load.
>>>> We thought it would be faster because it doesn't need to load anything
>>>> from memory.
>>>
>>> For good value (0x800000000) it should use only 2-3 instructions.
>>> I think you can keep using set().
>>>
>>>>>
>>>>> I can't find where in CDS you store information about compressed 
>>>>> klass
>>>>> pointers and compressed oops parameters which were used during dump?
>>>>> How you verify that correct parameters/flags are ussed when such CDS
>>>>> is used later?
>>>> No compressed klass pointers nor compressed oops get written to the
>>>> archive.  So, the compressed klass pointers and compressed oops
>>>> parameters do not need to be recorded in the archive.
>>>
>>> So you are saying that all klass pointers (references to klasses) in
>>> metadata structures in metaspace are full.
>>
>> Yes, they are.  (methodOops weren't in the InstanceKlass::_methods array
>> with Permgen but they are uncompressed now).
>>
>>> And klass pointers are only compressed in java object headers (which
>>> are not part of CDS). Right?
>>
>> The InstanceKlass has offsets to fields in the instance, and they depend
>> on both compressed oops and compressed klass pointers.   So both have to
>> be on for the offsets to be valid.
>>
>> But the base and compressed values are not stored anywhere in the CDS
>> archive.
>>
>>> And you don't care about UseCompressedOops and
>>> UseCompressedKlassPointers flags settings when you dump it into
>>> archive. The only limit is:
>>>
>>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total
>>>
>>> Then I don't understand why you can't use/load CDS archive when coop
>>> or compklass are off:
>>>
>>> > If coop is turned off then CDS cannot be used.  CDS will only be
>>> > supported if both UseCompressedOops and UseCompressedKlassPointers 
>>> are
>>> > TRUE.
>>>
>>> Also based on code in arguments.cpp it is allowed to specify
>>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command line:
>>>
>>> 1466     // Turn on UseCompressedKlassPointers too
>>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>>> 1469     }
>>>
>>> Did you tested such combination?
>>
>> I should let Harold answer this but I believe this is what his test
>> does.  For CDS on 64 bit, both must be on.   We didn't want to create 4
>> different archives.   And it wouldn't make too much sense since CDS for
>> 64 bit is a footprint savings so why would you use it without
>> compressing oops and class pointers?  It's not a startup savings on
>> server because we turn off interpreter bytecode quickening.
>>
>> Coleen
>>
>>>
>>>>>
>>>>> set_narrow_klass_base_and_shift() and
>>>>> can_use_cds_with_metaspace_addr() have the same code for
>>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>>>> can_use_cds_with_metaspace_addr() from
>>>>> set_narrow_klass_base_and_shift() ?
>>>> I could add new inlined methods that determine the higher_address and
>>>> lower_base when UseSharedSpaces is true and have them called from
>>>> set_narrow_klass_base_and_shift() and
>>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>>>
>>> I tried several approaches but your implementation is more clean. So I
>>> agree to keep what you have now.
>>>
>>>
>>> Also I found strange assert which should always fail (old code in
>>> global_initialize() in metaspace.cpp):
>>>
>>> 2959     if (UseSharedSpaces) {
>>> ...
>>> 2969       } else {
>>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>>> 2971                "archive file not closed or shared spaces not
>>> disabled.");
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>>
>>>>> I see that you unconditionally set comp klass ptr base and shift for
>>>>> DumpSharedSpaces. Should you do the check similar to
>>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>>>>> don't even check UseCompressedKlassPointers.
>>>> I don't think the checks are needed because the information written to
>>>> the archive is not affected by the size of the class metaspace.
>>>>
>>>> Also, I recently added code to arguments.cpp that will generate an 
>>>> error
>>>> if UseCompressedOops or UseCompressedKlassPointers is turned off and
>>>> DumpSharedSpaces is on.
>>>>>
>>>>> Why you have next limitation? What if coop can't be used because of
>>>>> big heap?:
>>>>>
>>>>> +     // UseCompressedOops and UseCompressedKlassPointers must be on
>>>>> for UseSharedSpaces.
>>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>> +       no_shared_spaces();
>>>> If coop is turned off then CDS cannot be used.  CDS will only be
>>>> supported if both UseCompressedOops and UseCompressedKlassPointers are
>>>> TRUE.
>>>>>
>>>>> Could you move UseCompressedKlassPointers code in arguments.cpp into
>>>>> separate method similar to set_use_compressed_oops()?
>>>> Done.
>>>>>
>>>>> About new tests.
>>>>> The first test in CDSCompressedKPtrsError misses
>>>>> -XX:+UseCompressedOops flag.
>>>> Fixed.
>>>>>
>>>>> Could you also test cross flags combinations?:
>>>>>
>>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>>> Done.
>>>>>
>>>>> It would be nice to have test to check ClassMetaspaceSize value 
>>>>> range.
>>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint
>>>>> or maxuint.
>>>> A member of our runtime SQE group is writing additional tests. I'll 
>>>> ask
>>>> him to write a ClassMetaspaceSize range test.
>>>>
>>>> We chose 3Gb because we thought it was a sufficiently large size.
>>>>>
>>>>>
>>>>> About code style, indention. We align next line to corresponding part
>>>>> of previous line if we need to split a line. And sometimes it is
>>>>> better to keep one long line. I understand some of them were before
>>>>> your changes but, please, clean up at lest ones you touched.
>>>> Done.
>>>>>
>>>>> Cases in metaspace.cpp:
>>>>>
>>>>> 2263   assert(raw_word_size >= min_size,
>>>>> 2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<"
>>>>> SIZE_FORMAT, word_size, min_size));
>>>>>
>>>>>
>>>>> 2485   if (Metaspace::using_class_space() &&
>>>>> 2486     (Metaspace::class_space_list() != NULL)) {
>>>>>
>>>>>
>>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>>>> 2575                       (Metaspace::using_class_space() ?
>>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>>>
>>>>>
>>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>>>> SIZE_FORMAT ", "
>>>>> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT
>>>>> ", "
>>>>> 2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>>>> ", "
>>>>> 2697                            "large count " SIZE_FORMAT,
>>>>> 2698              cls_specialized_count, cls_specialized_waste,
>>>>> 2699              cls_small_count, cls_small_waste,
>>>>> 2700              cls_medium_count, cls_medium_waste,
>>>>> cls_humongous_count);
>>>>>
>>>>>
>>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G > 
>>>>> addr) &&
>>>>> 2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>>>
>>>>>
>>>>> 2889         vm_exit_during_initialization(err_msg(
>>>>> 2890           "Could not allocate metaspace: %d bytes",
>>>>> 2891           class_metaspace_size()));
>>>>>
>>>>>
>>>>> 3107     return using_class_space() ?
>>>>> 3108       class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>>>
>>>>>
>>>>> 3157     if (is_class && using_class_space()) {
>>>>> 3158        class_vsm()->deallocate(ptr, word_size);
>>>>>
>>>>>
>>>>> 3305   return space_list()->contains(ptr) ||
>>>>> 3306     (using_class_space() && class_space_list()->contains(ptr));
>>>>>
>>>>> metaspace.hpp:
>>>>>
>>>>>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
>>>>>  271       (Metaspace::using_class_space() ?
>>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>>>
>>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>>>>>  286       (Metaspace::using_class_space() ?
>>>>>  287         _allocated_used_words[Metaspace::ClassType] : 0);
>>>>>
>>>>> universe.cpp:
>>>>>
>>>>>  849   assert((intptr_t)Universe::narrow_oop_base() <=
>>>>> (intptr_t)(Universe::heap()->base() -
>>>>>  850     os::vm_page_size()) ||
>>>>>  851            Universe::narrow_oop_base() == NULL, "invalid 
>>>>> value");
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this updated webrev for bug 8003424:
>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>>>
>>>>>> The updated webrev has a lot of changes from the previous webrev,
>>>>>> including the following:
>>>>>>
>>>>>>     1. Class metaspace information is now output when
>>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>>>>
>>>>>>     2. decode_klass_not_null(Register dst, Register src) no longer
>>>>>>     clobbers R12.
>>>>>>
>>>>>>     3. Method using_class_vsm() was renamed to using_class_space().
>>>>>>
>>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>>>>>> appropriate.
>>>>>>
>>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>>>>> unnecessary.
>>>>>>
>>>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>>>
>>>>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>>>>>> updated.
>>>>>>
>>>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005,
>>>>>> and
>>>>>> specjbb2013.  The results showed no significant performance 
>>>>>> difference
>>>>>> in terms of scores and gc behavior.
>>>>>>
>>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>>>>>
>>>>>> Please let me know what additional tests should be run.
>>>>>>
>>>>>> Thanks!
>>>>>> Harold
>>>>>>
>>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>>>> Hi Harold,
>>>>>>>
>>>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which 
>>>>>>> means
>>>>>>> that
>>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>>>> unless
>>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>>>> make
>>>>>>> sense?
>>>>>>>
>>>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000
>>>>>>> and I
>>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>>>>>> (assuming or
>>>>>>> with check that class metaspace size < 32Gb).
>>>>>>>
>>>>>>> > Is there one prefix byte per instruction, or just for certain
>>>>>>> instructions?
>>>>>>>
>>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>>>>>> prefix is
>>>>>>> necessary only if an instruction references one of the extended
>>>>>>> registers or uses a 64-bit operand."
>>>>>>>
>>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and 
>>>>>>> =32
>>>>>>> and big java heap. Recently we got several bugs which indicated 
>>>>>>> that
>>>>>>> we did not separate cleanly oops and klass pointers en/decoding.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>>>>> Hi Vladimir,
>>>>>>>>
>>>>>>>> Thank you for the review!  Please see inline comments.
>>>>>>>>
>>>>>>>> Thanks, Harold
>>>>>>>>
>>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>>>>>> Nice clean up, Harold
>>>>>>>>>>
>>>>>>>>>> Could you add the size of class metaspace in output with
>>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>>>>>>>> remember an
>>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>>>>>> Will be done in next webrev.
>>>>>>>>>>
>>>>>>>>>> Also it would be nice to print these info line (and compressed
>>>>>>>>>> oops
>>>>>>>>>> info
>>>>>>>>>> line) in hs_err files.
>>>>>>>> I filed an enhancement bug for this: 8021264
>>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>>>>>
>>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>>>>>>>>>> x86_64.ad.
>>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use 
>>>>>>>>>> arithmetic
>>>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also
>>>>>>>>>> note
>>>>>>>>>> that code in .ad file does not check the encoding mode for 
>>>>>>>>>> narrow
>>>>>>>>>> klass/oop so it should be conservative and assume that 
>>>>>>>>>> arithmetic
>>>>>>>>>> instructions are used.
>>>>>>>> OK. Thanks.
>>>>>>>>>>
>>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>>>>>>>>>> 4Gb so
>>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>>>>>> encoding/decoding without destroying R12.
>>>>>>>>>
>>>>>>>>> Correction. You can do it only if base < 2Gb max positive int 
>>>>>>>>> (sign
>>>>>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>>>>>> But the base will normally be 32Gb.  So this case won't happen 
>>>>>>>> very
>>>>>>>> often.
>>>>>>>>>
>>>>>>>>> You definitely should not use R12 in 
>>>>>>>>> decode_klass_not_null(Register
>>>>>>>>> dst, Register src) method where you have free 'dst' register.
>>>>>>>> Will be fixed in next webrev.
>>>>>>>>>
>>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 
>>>>>>>>> 64Gb.
>>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>>>>>
>>>>>>>>> decode:
>>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>>>>>   }
>>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= 
>>>>>>>>> maxint
>>>>>>>>> (max positive int).
>>>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>>>>>>>> that
>>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>>>>> unless
>>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>>>>> make
>>>>>>>> sense?
>>>>>>>>>
>>>>>>>>> And you have general memory reservation problem. At least on
>>>>>>>>> Solaris,
>>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
>>>>>>>>> between
>>>>>>>>> different requested memory regions. That is why in jdk7 we first
>>>>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>>>>>> compressed oops.
>>>>>>>>>
>>>>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>>>>>>> compressed
>>>>>>>>> oops and with Xmx20Gb.
>>>>>>>> I verifed that we get either cds_address+cds_total as the
>>>>>>>> address, or
>>>>>>>> CompressedKlassPointersBase as the address without CDS on Linux,
>>>>>>>> Windows
>>>>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap
>>>>>>>> sizes and
>>>>>>>> -Xmx32G.
>>>>>>>>
>>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the
>>>>>>>> desired
>>>>>>>> CDS address for class metaspace regardless of heap size.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>>>>>>>>> unfortunately we
>>>>>>>>>> can't do other way. I assume you use max size because 
>>>>>>>>>> depending on
>>>>>>>>>> registers used in instructions you will or will not get prefix
>>>>>>>>>> byte
>>>>>>>>>> (r8-r15).
>>>>>>>> Is there one prefix byte per instruction, or just for certain
>>>>>>>> instructions?
>>>>>>>>>>
>>>>>>>>>> I will look on changes in more details may be late.
>>>>>>>>>
>>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use 
>>>>>>>>> abbreviations
>>>>>>>>> which are not obvious.
>>>>>>>> I changed using_class_vsm() to using_class_space().
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Please review this fix for bug 8003424.
>>>>>>>>>>>
>>>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>>>>>> Open bug links at:
>>>>>>>>>>>
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>>>>>
>>>>>>>>>>> JBS Bug links at
>>>>>>>>>>>
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This fix provides support for using compressed klass pointers
>>>>>>>>>>> with
>>>>>>>>>>> CDS.
>>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>>>>>>>>>> platforms
>>>>>>>>>>> when
>>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the
>>>>>>>>>>> class
>>>>>>>>>>> metaspace as part of the Java Heap allocation and locating 
>>>>>>>>>>> it at
>>>>>>>>>>> the
>>>>>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>>>>>> separately,
>>>>>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>>>>>> metaspace
>>>>>>>>>>> because it won't be backed up against the Java heap. If CDS is
>>>>>>>>>>> being
>>>>>>>>>>> used, then the CDS region will be allocated between the Java
>>>>>>>>>>> heap and
>>>>>>>>>>> the metaspace.
>>>>>>>>>>>
>>>>>>>>>>> The new class metaspace allocation code tries to allocate
>>>>>>>>>>> memory at
>>>>>>>>>>> 32G,
>>>>>>>>>>> or above the CDS region, if it is present. Because of this,
>>>>>>>>>>> encoding
>>>>>>>>>>> and decoding of compressed klass pointers will always 
>>>>>>>>>>> require use
>>>>>>>>>>> of a
>>>>>>>>>>> base register.  So, encoding and decoding of compressed klass
>>>>>>>>>>> pointers
>>>>>>>>>>> will differ from compressed oops.
>>>>>>>>>>>
>>>>>>>>>>> There are no class metaspace allocation changes if
>>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
>>>>>>>>>>> 32-bit
>>>>>>>>>>> platform.
>>>>>>>>>>>
>>>>>>>>>>> The code changes also include some cleanup and will fix bugs
>>>>>>>>>>> 8016729,
>>>>>>>>>>> 8011610, and 8003424.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Many of the modules in this webrev contain a lot of changes.
>>>>>>>>>>> Modules
>>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>>>>>>>>>> changed to
>>>>>>>>>>> support the new encoding and decoding of compressed klass
>>>>>>>>>>> pointers.
>>>>>>>>>>>
>>>>>>>>>>> Module metaspace.cpp was changed significantly to support 
>>>>>>>>>>> the new
>>>>>>>>>>> allocation for metaspace and the CDS region and to determine
>>>>>>>>>>> compressed
>>>>>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>>>>>
>>>>>>>>>>> Most of the changes to module universe.cpp were to remove code
>>>>>>>>>>> related
>>>>>>>>>>> to allocating metaspace and remove code that considered
>>>>>>>>>>> compressed
>>>>>>>>>>> klass
>>>>>>>>>>> pointers when determining the compressed oops compression
>>>>>>>>>>> mechanism.
>>>>>>>>>>>
>>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as 
>>>>>>>>>>> part
>>>>>>>>>>> of a
>>>>>>>>>>> cleanup requested by Coleen.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
>>>>>>>>>>> tests,
>>>>>>>>>>> JPRT,
>>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and 
>>>>>>>>>>> vm.mlvm.testlist
>>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and 
>>>>>>>>>>> -Xshare:off
>>>>>>>>>>> (with
>>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit 
>>>>>>>>>>> Linux and
>>>>>>>>>>> 64-Bit
>>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests
>>>>>>>>>>> were
>>>>>>>>>>> run on Solaris x86.
>>>>>>>>>>>
>>>>>>>>>>> The performance impact of these changes is TBD.
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Harold
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>


From ioi.lam at oracle.com  Thu Aug  8 16:11:57 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 08 Aug 2013 16:11:57 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52040D1E.9000101@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com>
Message-ID: <520425BD.6090605@oracle.com>

|I found one version of JDK7 that does not crash:||
||
sc11136754 ~$ 
/net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
-showversion -cp . -Xbootclasspath/a:foo.jar test2
Error occurred during initialization of VM
java/lang/ClassNotFoundException: error in opening JAR file foo.jar
||
||
||- Ioi
|
On 08/08/2013 02:26 PM, Ioi Lam wrote:
> |I found an official version that's closest to the Redhat version 
> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still 
> crashes.||
> ||
> ||sc11136754 ~$ /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java 
> -showversion -cp . -Xbootclasspath/a:foo.jar test2||
> ||java version "1.6.0_25"||
> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
> ||
> ||java.lang.ClassNotFoundException ||
> || - klass: 'java/lang/ClassNotFoundException'||
> ||#||
> ||# A fatal error has been detected by the Java Runtime Environment:||
> ||#||
> ||#  Internal Error (exceptions.cpp:397), pid=29955, tid=140608485558016||
> ||#  fatal error: ExceptionMark destructor expects no pending exceptions||
> ||#||
> ||# JRE version: 6.0_25-b06||
> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode 
> linux-amd64 compressed oops)||
> ||# An error report file with more information is saved as:||
> ||# /home/iklam/hs_err_pid29955.log||
> ||#||
> ||# If you would like to submit a bug report, please visit:||
> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
> ||#||
> ||Aborted (core dumped)||
> |
> - Ioi
>
> On 08/08/2013 02:18 PM, David Holmes wrote:
>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which apparently
>>> works differently
>>> (better?) than the official JDK6 build. Maybe Redhat fixed this in 
>>> their
>>> own repo??||
>>
>> Their hotspot version is much later - hs20 vs hs17
>>
>> David
>> -----
>>
>>> ||
>>> |
>>> |==OEL6================================================
>>> ||
>>> ||sc11136754 ~$ uname -a||
>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>> ||sc11136754 ~$ type java||
>>> ||java is hashed (/usr/bin/java)||
>>> ||sc11136754 ~$ java -version||
>>> ||java version "1.6.0_22"||
>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar 
>>> test2||
>>> ||Error occurred during initialization of VM||
>>> ||java/lang/ClassNotFoundException: error in opening JAR file foo.jar||
>>> ||
>>> ==OFFICIAL============================================
>>> ||
>>> sc11136754 ~$ /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>> java version "1.6.0_22"
>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  Internal Error (exceptions.cpp:367), pid=25167, tid=140510319580928
>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>> #
>>> # JRE version: 6.0_22-b04
>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>> linux-amd64 )
>>> # An error report file with more information is saved as:
>>> # /home/iklam/hs_err_pid25167.log
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>> #
>>> |
>>> |======================================================
>>> ||
>>> ||- Ioi|
>>>
>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>> Hi Ioi, David,
>>>>
>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>> stand-alone test case that doesn't require truncating JAR files in
>>>>> the JDK:||
>>>>> ||
>>>>> ||=========================||
>>>>> ||/*||
>>>>> ||javac test2.java||
>>>>> ||rm -f foo.jar||
>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>> ||touch foo.jar||
>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>> ||*/||
>>>>> ||
>>>>> ||public class test2 {||
>>>>> ||    public static void main(String args[]) {||
>>>>> ||        try {||
>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>> ||        } catch (Throwable t) {||
>>>>> ||            t.printStackTrace();||
>>>>> ||        }||
>>>>> ||    }||
>>>>> ||}||
>>>>> ||=========================||
>>>>> | |
>>>>> ||JDK6 works fine, but JDK7 would crash with the second "java -cp .
>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>> |
>>>> |I saw crash with the latest 6 update release with both test cases.
>>>> The crash seems to be at the same spot.
>>>> |
>>>>> |||
>>>>> ||So I think the correct fix is to restore the JDK6 behavior (not
>>>>> sure if it's already the same with your patch, but worth checking),
>>>>> and also add a new jtreg test into hotspot.||
>>>>> |
>>>> |I checked the jdk 6 code and those 3 methods which I changed look the
>>>> same as jdk 8.
>>>> Sure, I can add a jtreg test.
>>>> |
>>>>> |||
>>>>> ||Thanks||
>>>>> ||- Ioi||
>>>>> ||
>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>> |
>>>>>> |Hi Calvin, ||
>>>>>> | |
>>>>>> ||It seems to me that this code has a general problem with
>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>> declared with a last parameter of TRAPS and called with a CHECK_
>>>>>> macro. The way this code is written it does not seem to expect any
>>>>>> exceptions to be possible. I would check with Karen on this. ||
>>>>>> |
>>>> |I was thinking about that but that would involves a bit more changes.
>>>> I can give it a try.
>>>> |
>>>>>> || |
>>>>>> ||This addition seems unused: ||
>>>>>> | |
>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>> |
>>>> |It is required for the THROW_MSG().
>>>> It won't be needed if the method is declared with TRAPS as the last
>>>> parameter (I think).
>>>>
>>>> thanks,
>>>> Calvin
>>>> |
>>>>>> || |
>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing
>>>>>> exceptions - don't know what the thought process was there :) ||
>>>>>> | |
>>>>>> ||David ||
>>>>>> | |
>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>> |
>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce similar
>>>>>>> crash ||
>>>>>>> ||by trying to load a class from an empty jar which is in the ||
>>>>>>> ||bootclasspath. The following program can trigger the crash if 
>>>>>>> the ||
>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>> | |
>>>>>>> ||public class TestForName { ||
>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>> ||         try { ||
>>>>>>> ||             Class cls =
>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>> ||             System.out.println("Class = " + cls.getName()); ||
>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>> ||         } ||
>>>>>>> ||     } ||
>>>>>>> ||} ||
>>>>>>> | |
>>>>>>> ||The fix also changes the assert() in
>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>>>> above test ||
>>>>>>> ||scenario. ||
>>>>>>> | |
>>>>>>> ||With the fix, the following ClassNotFoundException will be 
>>>>>>> thrown ||
>>>>>>> ||instead of a crash: ||
>>>>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>>>>> ||         at 
>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>> ||         at 
>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>> ||         at java.security.AccessController.doPrivileged(Native
>>>>>>> Method) ||
>>>>>>> ||         at
>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>> ||         at 
>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>> ||         at
>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>>>>> ||         at 
>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>> | |
>>>>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>> | |
>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>> | |
>>>>>>> ||Tests: ||
>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>> | |
>>>>>>> ||thanks, ||
>>>>>>> ||Calvin ||
>>>>>>> | |
>>>>>>> | |
>>>>>>> |
>>>>> |
>>>>> |
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130808/fa7d3c01/attachment.html 

From coleen.phillimore at oracle.com  Thu Aug  8 16:21:29 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 08 Aug 2013 19:21:29 -0400
Subject: RFR 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
In-Reply-To: <520423B6.3050009@oracle.com>
References: <52016BBB.3040907@oracle.com> <520423B6.3050009@oracle.com>
Message-ID: <520427F9.8030805@oracle.com>


Thanks, Serguei!
Coleen

On 08/08/2013 07:03 PM, serguei.spitsyn at oracle.com wrote:
> Coleen,
>
> The fix looks good, I do not see any issues.
>
> Thanks,
> Serguei
>
>
> On 8/6/13 2:33 PM, Coleen Phillimore wrote:
>> Summary: ActiveMethodOopsCache was used to keep track of old versions 
>> of some methods that are cached in Universe but is buggy with permgen 
>> removal and not needed anymore
>>
>> There was a crash in this function that I couldn't reproduce. It was 
>> likely that the crash was for something else, but this is a lurking bug.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8009728/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009728
>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8009728
>>
>> Tested with vm.quick.testlist which includes redefine classes tests 
>> and jck lang and vm tests.
>>
>> Thanks,
>> Coleen
>


From coleen.phillimore at oracle.com  Thu Aug  8 16:59:47 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 08 Aug 2013 19:59:47 -0400
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <52041AC1.4000803@oracle.com>
References: <5201886C.1030206@oracle.com> <52024E1A.4000908@oracle.com>
	<520275B8.5010101@oracle.com> <52028A69.8010207@oracle.com>
	<52041AC1.4000803@oracle.com>
Message-ID: <520430F3.4040306@oracle.com>


Mikael,

I think this looks great.  It's a lot cleaner (more red than blue changes).

thanks for humoring me,
Coleen

On 08/08/2013 06:25 PM, Mikael Vidstedt wrote:
>
> Coleen,
>
> After having tried numerous different versions I ended up with this:
>
> http://cr.openjdk.java.net/~mikael/webrevs/8022452.3/webrev
>
> Summary of the changes:
>
> * The GetNativeSystemInfo call has been moved up before the switch, 
> but is only called if the os version is recent enough, and  we 
> actually care about the si.wProcessorArchitecture field.
>
> * The true/else branches in the if-diamond have been switch to avoid 
> the negation of the condition.
>
> * While at it I added support for recognizing "Windows Server 2008 R2" 
> (6.1 non-workstation) which we apparently haven't recognized earlier, 
> but which is something the JDK code recognizes [1].
>
> * The " , 64 bit" has been move out below the switch, but is only 
> relevant/tested for on recent enough Windows versions, just like the 
> old code did.
>
> Feedback much appreciated! I'm also investigating if it would be 
> possible to unify/share the code with the java_props_md.c logic [1] to 
> avoid the duplication, but for now this may have to do. In addition to 
> that the code can be cleaned up further if we only support VS2010+, 
> which I believe is de facto since JDK 7 anyway; I will investigate 
> that as a separate improvement.
>
> Thanks,
> Mikael
>
> [1] 
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/e057cddf0d6c/src/windows/native/java/lang/java_props_md.c 
> (line 451).
>
> On 2013-08-07 10:56, Coleen Phillimore wrote:
>>
>> Mikael,
>>
>> I do like your new version better but because you changed so much, it 
>> should be verified on all versions of windows.   Which you might not 
>> want to do.   My suggestion to make this code nicer (fix case stmt 
>> and outline common code) was really simple and I think can be 
>> verified by code inspection, which might be less work and easier to 
>> review.
>>
>> Coleen
>>
>> On 8/7/2013 12:28 PM, Mikael Vidstedt wrote:
>>>
>>> Coleen,
>>>
>>> Funny you should mention that, and since I fully agree with you I 
>>> actually did prepare another version of the patch which is heavily 
>>> inspired by the java_props_md.c implementation:
>>>
>>> http://cr.openjdk.java.net/~mikael/webrevs/winvercleanup2/webrev/
>>>
>>> I personally like this version better, but the one thing that held 
>>> me back was the fact that I will basically want to dig up machines 
>>> with all the different (supported) Windows versions and verify that 
>>> the code is still correct in all cases. If you think this is the way 
>>> to go I more than willing to will do so. Let me know what you think 
>>> about the new version of the patch!
>>>
>>> There's no real urgency here - I'd rather do it correct once than...
>>>
>>> Cheers,
>>> Mikael
>>>
>>>
>>> On 2013-08-07 06:39, Coleen Phillimore wrote:
>>>>
>>>> It looks like the code under the case for all these releases, 
>>>> should be different case statements for each, rather than these 
>>>> cascading 'if' statements.  And make 1668-1673 a new function 
>>>> returning si.   So if we have a new release, in general it will 
>>>> work because the default will print out something.   But a better 
>>>> default would be lines 1712-1717 which are dead code now.
>>>>
>>>> Sorry, I know it's simple and urgent but this seems to be getting 
>>>> increasingly ugly.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>>>>>
>>>>> Please review the following change:
>>>>>
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>>>>>
>>>>> The patch adds support to os_windows.cpp for recognizing the 
>>>>> upcoming Windows versions: Windows 8.1 and Windows Server 2012 R2.
>>>>>
>>>>> The changed is based on the corresponding code on the JDK 
>>>>> side[1][2][3].
>>>>>
>>>>> Thanks,
>>>>> Mikael
>>>>>
>>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
>>>>> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
>>>>> [3] 
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>>>>>
>>>>
>>>
>>
>


From ioi.lam at oracle.com  Thu Aug  8 20:05:50 2013
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Fri, 09 Aug 2013 03:05:50 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022093: syntax error near
	"umpiconninfo_t" -- when building on Solaris 10
Message-ID: <20130809030555.BC59C48734@hg.openjdk.java.net>

Changeset: c661fa2e5189
Author:    iklam
Date:      2013-08-08 14:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c661fa2e5189

8022093: syntax error near "umpiconninfo_t" -- when building on Solaris 10
Summary: Added extra help message in make/solaris/makefiles/dtrace.make
Reviewed-by: dholmes, sspitsyn

! make/solaris/makefiles/dtrace.make


From dmitry.samersoff at oracle.com  Fri Aug  9 04:15:42 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 09 Aug 2013 15:15:42 +0400
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <520430F3.4040306@oracle.com>
References: <5201886C.1030206@oracle.com> <52024E1A.4000908@oracle.com>
	<520275B8.5010101@oracle.com> <52028A69.8010207@oracle.com>
	<52041AC1.4000803@oracle.com> <520430F3.4040306@oracle.com>
Message-ID: <5204CF5E.30705@oracle.com>

Mikael,

Does we still support Win 95/98/Me ?

PS: Comments seems redundant to me

1660     // find out whether we are running on 64 bit processor or not.

-Dmitry

On 2013-08-09 03:59, Coleen Phillimore wrote:
> 
> Mikael,
> 
> I think this looks great.  It's a lot cleaner (more red than blue changes).
> 
> thanks for humoring me,
> Coleen
> 
> On 08/08/2013 06:25 PM, Mikael Vidstedt wrote:
>>
>> Coleen,
>>
>> After having tried numerous different versions I ended up with this:
>>
>> http://cr.openjdk.java.net/~mikael/webrevs/8022452.3/webrev
>>
>> Summary of the changes:
>>
>> * The GetNativeSystemInfo call has been moved up before the switch,
>> but is only called if the os version is recent enough, and  we
>> actually care about the si.wProcessorArchitecture field.
>>
>> * The true/else branches in the if-diamond have been switch to avoid
>> the negation of the condition.
>>
>> * While at it I added support for recognizing "Windows Server 2008 R2"
>> (6.1 non-workstation) which we apparently haven't recognized earlier,
>> but which is something the JDK code recognizes [1].
>>
>> * The " , 64 bit" has been move out below the switch, but is only
>> relevant/tested for on recent enough Windows versions, just like the
>> old code did.
>>
>> Feedback much appreciated! I'm also investigating if it would be
>> possible to unify/share the code with the java_props_md.c logic [1] to
>> avoid the duplication, but for now this may have to do. In addition to
>> that the code can be cleaned up further if we only support VS2010+,
>> which I believe is de facto since JDK 7 anyway; I will investigate
>> that as a separate improvement.
>>
>> Thanks,
>> Mikael
>>
>> [1]
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/e057cddf0d6c/src/windows/native/java/lang/java_props_md.c
>> (line 451).
>>
>> On 2013-08-07 10:56, Coleen Phillimore wrote:
>>>
>>> Mikael,
>>>
>>> I do like your new version better but because you changed so much, it
>>> should be verified on all versions of windows.   Which you might not
>>> want to do.   My suggestion to make this code nicer (fix case stmt
>>> and outline common code) was really simple and I think can be
>>> verified by code inspection, which might be less work and easier to
>>> review.
>>>
>>> Coleen
>>>
>>> On 8/7/2013 12:28 PM, Mikael Vidstedt wrote:
>>>>
>>>> Coleen,
>>>>
>>>> Funny you should mention that, and since I fully agree with you I
>>>> actually did prepare another version of the patch which is heavily
>>>> inspired by the java_props_md.c implementation:
>>>>
>>>> http://cr.openjdk.java.net/~mikael/webrevs/winvercleanup2/webrev/
>>>>
>>>> I personally like this version better, but the one thing that held
>>>> me back was the fact that I will basically want to dig up machines
>>>> with all the different (supported) Windows versions and verify that
>>>> the code is still correct in all cases. If you think this is the way
>>>> to go I more than willing to will do so. Let me know what you think
>>>> about the new version of the patch!
>>>>
>>>> There's no real urgency here - I'd rather do it correct once than...
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>>
>>>> On 2013-08-07 06:39, Coleen Phillimore wrote:
>>>>>
>>>>> It looks like the code under the case for all these releases,
>>>>> should be different case statements for each, rather than these
>>>>> cascading 'if' statements.  And make 1668-1673 a new function
>>>>> returning si.   So if we have a new release, in general it will
>>>>> work because the default will print out something.   But a better
>>>>> default would be lines 1712-1717 which are dead code now.
>>>>>
>>>>> Sorry, I know it's simple and urgent but this seems to be getting
>>>>> increasingly ugly.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>>>>>>
>>>>>> Please review the following change:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>>>>>>
>>>>>> The patch adds support to os_windows.cpp for recognizing the
>>>>>> upcoming Windows versions: Windows 8.1 and Windows Server 2012 R2.
>>>>>>
>>>>>> The changed is based on the corresponding code on the JDK
>>>>>> side[1][2][3].
>>>>>>
>>>>>> Thanks,
>>>>>> Mikael
>>>>>>
>>>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
>>>>>> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
>>>>>> [3]
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 


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

From harold.seigel at oracle.com  Fri Aug  9 05:28:02 2013
From: harold.seigel at oracle.com (Harold Seigel)
Date: Fri, 9 Aug 2013 05:28:02 -0700 (PDT)
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
Message-ID: <60b2b73e-03f0-48d9-ac20-35f43b0f221b@default>

This is a bug that Stefan Karlsson also discovered.  To fix it, I've changed the code to this:

  if (DumpSharedSpaces) {
    if (RequireSharedSpaces) {
      warning("cannot dump shared archive while using shared archive");
    }
    UseSharedSpaces = false;
#ifdef _LP64
    if (!UseCompressedOops || !UseCompressedKlassPointers) {
      vm_exit_during_initialization(
        "Cannot dump shared archive when UseCompressedOops or UseCompressedKlassPointers is off.", NULL);
    }

Harold


----- Original Message -----
From: coleen.phillimore at oracle.com
To: hotspot-runtime-dev at openjdk.java.net
Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for CompressedOops


Yes, there should be a check for that too.  Now I'll really let Harold 
answer.

Thanks,
Coleen

On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
> Coleen, Harold
>
> > The InstanceKlass has offsets to fields in the instance, and they 
> depend
> > on both compressed oops and compressed klass pointers.   So both 
> have to
> > be on for the offsets to be valid.
>
> So there is dependency on UseCompressedOops and
> UseCompressedKlassPointers flags during dump.
>
> Then why the check is done only for UseSharedSpaces and not for 
> DumpSharedSpaces?:
>
>     if (DumpSharedSpaces) {
>       if (RequireSharedSpaces) {
>         warning("cannot dump shared archive while using shared archive");
>       }
>       UseSharedSpaces = false;
> + #ifdef _LP64
> +   } else {
> +     // UseCompressedOops and UseCompressedKlassPointers must be on 
> for UseSharedSpaces.
> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
> +       no_shared_spaces();
> +     }
> + #endif
>     }
>
> Thanks,
> Vladimir
>
> On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>>
>> Hi Vladimir,
>>
>> I have a couple of answers and I'll let Harold answer the rest.
>>
>> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>>> On 8/7/13 8:34 AM, harold seigel wrote:
>>>> Hi Vladimir,
>>>>
>>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>>>> Harold,
>>>>>
>>>>> Note, on SPARC set() could generate up to 8 instructions to load
>>>>> 64-bit constant into register. So I am not sure that it will be 
>>>>> faster
>>>>> than load.
>>>> We thought it would be faster because it doesn't need to load anything
>>>> from memory.
>>>
>>> For good value (0x800000000) it should use only 2-3 instructions.
>>> I think you can keep using set().
>>>
>>>>>
>>>>> I can't find where in CDS you store information about compressed 
>>>>> klass
>>>>> pointers and compressed oops parameters which were used during dump?
>>>>> How you verify that correct parameters/flags are ussed when such CDS
>>>>> is used later?
>>>> No compressed klass pointers nor compressed oops get written to the
>>>> archive.  So, the compressed klass pointers and compressed oops
>>>> parameters do not need to be recorded in the archive.
>>>
>>> So you are saying that all klass pointers (references to klasses) in
>>> metadata structures in metaspace are full.
>>
>> Yes, they are.  (methodOops weren't in the InstanceKlass::_methods array
>> with Permgen but they are uncompressed now).
>>
>>> And klass pointers are only compressed in java object headers (which
>>> are not part of CDS). Right?
>>
>> The InstanceKlass has offsets to fields in the instance, and they depend
>> on both compressed oops and compressed klass pointers.   So both have to
>> be on for the offsets to be valid.
>>
>> But the base and compressed values are not stored anywhere in the CDS
>> archive.
>>
>>> And you don't care about UseCompressedOops and
>>> UseCompressedKlassPointers flags settings when you dump it into
>>> archive. The only limit is:
>>>
>>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total
>>>
>>> Then I don't understand why you can't use/load CDS archive when coop
>>> or compklass are off:
>>>
>>> > If coop is turned off then CDS cannot be used.  CDS will only be
>>> > supported if both UseCompressedOops and UseCompressedKlassPointers 
>>> are
>>> > TRUE.
>>>
>>> Also based on code in arguments.cpp it is allowed to specify
>>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command line:
>>>
>>> 1466     // Turn on UseCompressedKlassPointers too
>>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>>> 1469     }
>>>
>>> Did you tested such combination?
>>
>> I should let Harold answer this but I believe this is what his test
>> does.  For CDS on 64 bit, both must be on.   We didn't want to create 4
>> different archives.   And it wouldn't make too much sense since CDS for
>> 64 bit is a footprint savings so why would you use it without
>> compressing oops and class pointers?  It's not a startup savings on
>> server because we turn off interpreter bytecode quickening.
>>
>> Coleen
>>
>>>
>>>>>
>>>>> set_narrow_klass_base_and_shift() and
>>>>> can_use_cds_with_metaspace_addr() have the same code for
>>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>>>> can_use_cds_with_metaspace_addr() from
>>>>> set_narrow_klass_base_and_shift() ?
>>>> I could add new inlined methods that determine the higher_address and
>>>> lower_base when UseSharedSpaces is true and have them called from
>>>> set_narrow_klass_base_and_shift() and
>>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>>>
>>> I tried several approaches but your implementation is more clean. So I
>>> agree to keep what you have now.
>>>
>>>
>>> Also I found strange assert which should always fail (old code in
>>> global_initialize() in metaspace.cpp):
>>>
>>> 2959     if (UseSharedSpaces) {
>>> ...
>>> 2969       } else {
>>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>>> 2971                "archive file not closed or shared spaces not
>>> disabled.");
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>>
>>>>> I see that you unconditionally set comp klass ptr base and shift for
>>>>> DumpSharedSpaces. Should you do the check similar to
>>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>>>>> don't even check UseCompressedKlassPointers.
>>>> I don't think the checks are needed because the information written to
>>>> the archive is not affected by the size of the class metaspace.
>>>>
>>>> Also, I recently added code to arguments.cpp that will generate an 
>>>> error
>>>> if UseCompressedOops or UseCompressedKlassPointers is turned off and
>>>> DumpSharedSpaces is on.
>>>>>
>>>>> Why you have next limitation? What if coop can't be used because of
>>>>> big heap?:
>>>>>
>>>>> +     // UseCompressedOops and UseCompressedKlassPointers must be on
>>>>> for UseSharedSpaces.
>>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>> +       no_shared_spaces();
>>>> If coop is turned off then CDS cannot be used.  CDS will only be
>>>> supported if both UseCompressedOops and UseCompressedKlassPointers are
>>>> TRUE.
>>>>>
>>>>> Could you move UseCompressedKlassPointers code in arguments.cpp into
>>>>> separate method similar to set_use_compressed_oops()?
>>>> Done.
>>>>>
>>>>> About new tests.
>>>>> The first test in CDSCompressedKPtrsError misses
>>>>> -XX:+UseCompressedOops flag.
>>>> Fixed.
>>>>>
>>>>> Could you also test cross flags combinations?:
>>>>>
>>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>>> Done.
>>>>>
>>>>> It would be nice to have test to check ClassMetaspaceSize value 
>>>>> range.
>>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint
>>>>> or maxuint.
>>>> A member of our runtime SQE group is writing additional tests. I'll 
>>>> ask
>>>> him to write a ClassMetaspaceSize range test.
>>>>
>>>> We chose 3Gb because we thought it was a sufficiently large size.
>>>>>
>>>>>
>>>>> About code style, indention. We align next line to corresponding part
>>>>> of previous line if we need to split a line. And sometimes it is
>>>>> better to keep one long line. I understand some of them were before
>>>>> your changes but, please, clean up at lest ones you touched.
>>>> Done.
>>>>>
>>>>> Cases in metaspace.cpp:
>>>>>
>>>>> 2263   assert(raw_word_size >= min_size,
>>>>> 2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<"
>>>>> SIZE_FORMAT, word_size, min_size));
>>>>>
>>>>>
>>>>> 2485   if (Metaspace::using_class_space() &&
>>>>> 2486     (Metaspace::class_space_list() != NULL)) {
>>>>>
>>>>>
>>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>>>> 2575                       (Metaspace::using_class_space() ?
>>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>>>
>>>>>
>>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>>>> SIZE_FORMAT ", "
>>>>> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT
>>>>> ", "
>>>>> 2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>>>> ", "
>>>>> 2697                            "large count " SIZE_FORMAT,
>>>>> 2698              cls_specialized_count, cls_specialized_waste,
>>>>> 2699              cls_small_count, cls_small_waste,
>>>>> 2700              cls_medium_count, cls_medium_waste,
>>>>> cls_humongous_count);
>>>>>
>>>>>
>>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G > 
>>>>> addr) &&
>>>>> 2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>>>
>>>>>
>>>>> 2889         vm_exit_during_initialization(err_msg(
>>>>> 2890           "Could not allocate metaspace: %d bytes",
>>>>> 2891           class_metaspace_size()));
>>>>>
>>>>>
>>>>> 3107     return using_class_space() ?
>>>>> 3108       class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>>>
>>>>>
>>>>> 3157     if (is_class && using_class_space()) {
>>>>> 3158        class_vsm()->deallocate(ptr, word_size);
>>>>>
>>>>>
>>>>> 3305   return space_list()->contains(ptr) ||
>>>>> 3306     (using_class_space() && class_space_list()->contains(ptr));
>>>>>
>>>>> metaspace.hpp:
>>>>>
>>>>>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
>>>>>  271       (Metaspace::using_class_space() ?
>>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>>>
>>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>>>>>  286       (Metaspace::using_class_space() ?
>>>>>  287         _allocated_used_words[Metaspace::ClassType] : 0);
>>>>>
>>>>> universe.cpp:
>>>>>
>>>>>  849   assert((intptr_t)Universe::narrow_oop_base() <=
>>>>> (intptr_t)(Universe::heap()->base() -
>>>>>  850     os::vm_page_size()) ||
>>>>>  851            Universe::narrow_oop_base() == NULL, "invalid 
>>>>> value");
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this updated webrev for bug 8003424:
>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>>>
>>>>>> The updated webrev has a lot of changes from the previous webrev,
>>>>>> including the following:
>>>>>>
>>>>>>     1. Class metaspace information is now output when
>>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>>>>
>>>>>>     2. decode_klass_not_null(Register dst, Register src) no longer
>>>>>>     clobbers R12.
>>>>>>
>>>>>>     3. Method using_class_vsm() was renamed to using_class_space().
>>>>>>
>>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>>>>>> appropriate.
>>>>>>
>>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>>>>> unnecessary.
>>>>>>
>>>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>>>
>>>>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>>>>>> updated.
>>>>>>
>>>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005,
>>>>>> and
>>>>>> specjbb2013.  The results showed no significant performance 
>>>>>> difference
>>>>>> in terms of scores and gc behavior.
>>>>>>
>>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>>>>>
>>>>>> Please let me know what additional tests should be run.
>>>>>>
>>>>>> Thanks!
>>>>>> Harold
>>>>>>
>>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>>>> Hi Harold,
>>>>>>>
>>>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which 
>>>>>>> means
>>>>>>> that
>>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>>>> unless
>>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>>>> make
>>>>>>> sense?
>>>>>>>
>>>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000
>>>>>>> and I
>>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>>>>>> (assuming or
>>>>>>> with check that class metaspace size < 32Gb).
>>>>>>>
>>>>>>> > Is there one prefix byte per instruction, or just for certain
>>>>>>> instructions?
>>>>>>>
>>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>>>>>> prefix is
>>>>>>> necessary only if an instruction references one of the extended
>>>>>>> registers or uses a 64-bit operand."
>>>>>>>
>>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and 
>>>>>>> =32
>>>>>>> and big java heap. Recently we got several bugs which indicated 
>>>>>>> that
>>>>>>> we did not separate cleanly oops and klass pointers en/decoding.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>>>>> Hi Vladimir,
>>>>>>>>
>>>>>>>> Thank you for the review!  Please see inline comments.
>>>>>>>>
>>>>>>>> Thanks, Harold
>>>>>>>>
>>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>>>>>> Nice clean up, Harold
>>>>>>>>>>
>>>>>>>>>> Could you add the size of class metaspace in output with
>>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>>>>>>>> remember an
>>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>>>>>> Will be done in next webrev.
>>>>>>>>>>
>>>>>>>>>> Also it would be nice to print these info line (and compressed
>>>>>>>>>> oops
>>>>>>>>>> info
>>>>>>>>>> line) in hs_err files.
>>>>>>>> I filed an enhancement bug for this: 8021264
>>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>>>>>
>>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>>>>>>>>>> x86_64.ad.
>>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use 
>>>>>>>>>> arithmetic
>>>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also
>>>>>>>>>> note
>>>>>>>>>> that code in .ad file does not check the encoding mode for 
>>>>>>>>>> narrow
>>>>>>>>>> klass/oop so it should be conservative and assume that 
>>>>>>>>>> arithmetic
>>>>>>>>>> instructions are used.
>>>>>>>> OK. Thanks.
>>>>>>>>>>
>>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>>>>>>>>>> 4Gb so
>>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>>>>>> encoding/decoding without destroying R12.
>>>>>>>>>
>>>>>>>>> Correction. You can do it only if base < 2Gb max positive int 
>>>>>>>>> (sign
>>>>>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>>>>>> But the base will normally be 32Gb.  So this case won't happen 
>>>>>>>> very
>>>>>>>> often.
>>>>>>>>>
>>>>>>>>> You definitely should not use R12 in 
>>>>>>>>> decode_klass_not_null(Register
>>>>>>>>> dst, Register src) method where you have free 'dst' register.
>>>>>>>> Will be fixed in next webrev.
>>>>>>>>>
>>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 
>>>>>>>>> 64Gb.
>>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>>>>>
>>>>>>>>> decode:
>>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>>>>>   }
>>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= 
>>>>>>>>> maxint
>>>>>>>>> (max positive int).
>>>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>>>>>>>> that
>>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>>>>> unless
>>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>>>>> make
>>>>>>>> sense?
>>>>>>>>>
>>>>>>>>> And you have general memory reservation problem. At least on
>>>>>>>>> Solaris,
>>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
>>>>>>>>> between
>>>>>>>>> different requested memory regions. That is why in jdk7 we first
>>>>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>>>>>> compressed oops.
>>>>>>>>>
>>>>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>>>>>>> compressed
>>>>>>>>> oops and with Xmx20Gb.
>>>>>>>> I verifed that we get either cds_address+cds_total as the
>>>>>>>> address, or
>>>>>>>> CompressedKlassPointersBase as the address without CDS on Linux,
>>>>>>>> Windows
>>>>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap
>>>>>>>> sizes and
>>>>>>>> -Xmx32G.
>>>>>>>>
>>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the
>>>>>>>> desired
>>>>>>>> CDS address for class metaspace regardless of heap size.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>>>>>>>>> unfortunately we
>>>>>>>>>> can't do other way. I assume you use max size because 
>>>>>>>>>> depending on
>>>>>>>>>> registers used in instructions you will or will not get prefix
>>>>>>>>>> byte
>>>>>>>>>> (r8-r15).
>>>>>>>> Is there one prefix byte per instruction, or just for certain
>>>>>>>> instructions?
>>>>>>>>>>
>>>>>>>>>> I will look on changes in more details may be late.
>>>>>>>>>
>>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use 
>>>>>>>>> abbreviations
>>>>>>>>> which are not obvious.
>>>>>>>> I changed using_class_vsm() to using_class_space().
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Please review this fix for bug 8003424.
>>>>>>>>>>>
>>>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>>>>>> Open bug links at:
>>>>>>>>>>>
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>>>>>
>>>>>>>>>>> JBS Bug links at
>>>>>>>>>>>
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This fix provides support for using compressed klass pointers
>>>>>>>>>>> with
>>>>>>>>>>> CDS.
>>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>>>>>>>>>> platforms
>>>>>>>>>>> when
>>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the
>>>>>>>>>>> class
>>>>>>>>>>> metaspace as part of the Java Heap allocation and locating 
>>>>>>>>>>> it at
>>>>>>>>>>> the
>>>>>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>>>>>> separately,
>>>>>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>>>>>> metaspace
>>>>>>>>>>> because it won't be backed up against the Java heap. If CDS is
>>>>>>>>>>> being
>>>>>>>>>>> used, then the CDS region will be allocated between the Java
>>>>>>>>>>> heap and
>>>>>>>>>>> the metaspace.
>>>>>>>>>>>
>>>>>>>>>>> The new class metaspace allocation code tries to allocate
>>>>>>>>>>> memory at
>>>>>>>>>>> 32G,
>>>>>>>>>>> or above the CDS region, if it is present. Because of this,
>>>>>>>>>>> encoding
>>>>>>>>>>> and decoding of compressed klass pointers will always 
>>>>>>>>>>> require use
>>>>>>>>>>> of a
>>>>>>>>>>> base register.  So, encoding and decoding of compressed klass
>>>>>>>>>>> pointers
>>>>>>>>>>> will differ from compressed oops.
>>>>>>>>>>>
>>>>>>>>>>> There are no class metaspace allocation changes if
>>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
>>>>>>>>>>> 32-bit
>>>>>>>>>>> platform.
>>>>>>>>>>>
>>>>>>>>>>> The code changes also include some cleanup and will fix bugs
>>>>>>>>>>> 8016729,
>>>>>>>>>>> 8011610, and 8003424.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Many of the modules in this webrev contain a lot of changes.
>>>>>>>>>>> Modules
>>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>>>>>>>>>> changed to
>>>>>>>>>>> support the new encoding and decoding of compressed klass
>>>>>>>>>>> pointers.
>>>>>>>>>>>
>>>>>>>>>>> Module metaspace.cpp was changed significantly to support 
>>>>>>>>>>> the new
>>>>>>>>>>> allocation for metaspace and the CDS region and to determine
>>>>>>>>>>> compressed
>>>>>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>>>>>
>>>>>>>>>>> Most of the changes to module universe.cpp were to remove code
>>>>>>>>>>> related
>>>>>>>>>>> to allocating metaspace and remove code that considered
>>>>>>>>>>> compressed
>>>>>>>>>>> klass
>>>>>>>>>>> pointers when determining the compressed oops compression
>>>>>>>>>>> mechanism.
>>>>>>>>>>>
>>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as 
>>>>>>>>>>> part
>>>>>>>>>>> of a
>>>>>>>>>>> cleanup requested by Coleen.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
>>>>>>>>>>> tests,
>>>>>>>>>>> JPRT,
>>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and 
>>>>>>>>>>> vm.mlvm.testlist
>>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and 
>>>>>>>>>>> -Xshare:off
>>>>>>>>>>> (with
>>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit 
>>>>>>>>>>> Linux and
>>>>>>>>>>> 64-Bit
>>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests
>>>>>>>>>>> were
>>>>>>>>>>> run on Solaris x86.
>>>>>>>>>>>
>>>>>>>>>>> The performance impact of these changes is TBD.
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Harold
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>


From harold.seigel at oracle.com  Fri Aug  9 05:42:44 2013
From: harold.seigel at oracle.com (Harold Seigel)
Date: Fri, 9 Aug 2013 05:42:44 -0700 (PDT)
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
Message-ID: <42ed9a54-9c79-4362-8ed2-fe146eb29446@default>

The purpose of this assert is to verify that the two methods in the 'if' clause closed the map file and disabled UseSharedSpaces if they detected a problem when trying to use CDS.  

      if (mapinfo->initialize() && MetaspaceShared::map_shared_spaces(mapinfo)) {
        FileMapInfo::set_current_info(mapinfo);
      } else {
        assert(!mapinfo->is_open() && !UseSharedSpaces,
               "archive file not closed or shared spaces not disabled.");
      }

----- Original Message -----
From: harold.seigel at oracle.com
To: coleen.phillimore at oracle.com
Cc: hotspot-runtime-dev at openjdk.java.net
Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for CompressedOops

This is a bug that Stefan Karlsson also discovered.  To fix it, I've changed the code to this:

  if (DumpSharedSpaces) {
    if (RequireSharedSpaces) {
      warning("cannot dump shared archive while using shared archive");
    }
    UseSharedSpaces = false;
#ifdef _LP64
    if (!UseCompressedOops || !UseCompressedKlassPointers) {
      vm_exit_during_initialization(
        "Cannot dump shared archive when UseCompressedOops or UseCompressedKlassPointers is off.", NULL);
    }

Harold


----- Original Message -----
From: coleen.phillimore at oracle.com
To: hotspot-runtime-dev at openjdk.java.net
Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for CompressedOops


Yes, there should be a check for that too.  Now I'll really let Harold 
answer.

Thanks,
Coleen

On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
> Coleen, Harold
>
> > The InstanceKlass has offsets to fields in the instance, and they 
> depend
> > on both compressed oops and compressed klass pointers.   So both 
> have to
> > be on for the offsets to be valid.
>
> So there is dependency on UseCompressedOops and
> UseCompressedKlassPointers flags during dump.
>
> Then why the check is done only for UseSharedSpaces and not for 
> DumpSharedSpaces?:
>
>     if (DumpSharedSpaces) {
>       if (RequireSharedSpaces) {
>         warning("cannot dump shared archive while using shared archive");
>       }
>       UseSharedSpaces = false;
> + #ifdef _LP64
> +   } else {
> +     // UseCompressedOops and UseCompressedKlassPointers must be on 
> for UseSharedSpaces.
> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
> +       no_shared_spaces();
> +     }
> + #endif
>     }
>
> Thanks,
> Vladimir
>
> On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>>
>> Hi Vladimir,
>>
>> I have a couple of answers and I'll let Harold answer the rest.
>>
>> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>>> On 8/7/13 8:34 AM, harold seigel wrote:
>>>> Hi Vladimir,
>>>>
>>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>>>> Harold,
>>>>>
>>>>> Note, on SPARC set() could generate up to 8 instructions to load
>>>>> 64-bit constant into register. So I am not sure that it will be 
>>>>> faster
>>>>> than load.
>>>> We thought it would be faster because it doesn't need to load anything
>>>> from memory.
>>>
>>> For good value (0x800000000) it should use only 2-3 instructions.
>>> I think you can keep using set().
>>>
>>>>>
>>>>> I can't find where in CDS you store information about compressed 
>>>>> klass
>>>>> pointers and compressed oops parameters which were used during dump?
>>>>> How you verify that correct parameters/flags are ussed when such CDS
>>>>> is used later?
>>>> No compressed klass pointers nor compressed oops get written to the
>>>> archive.  So, the compressed klass pointers and compressed oops
>>>> parameters do not need to be recorded in the archive.
>>>
>>> So you are saying that all klass pointers (references to klasses) in
>>> metadata structures in metaspace are full.
>>
>> Yes, they are.  (methodOops weren't in the InstanceKlass::_methods array
>> with Permgen but they are uncompressed now).
>>
>>> And klass pointers are only compressed in java object headers (which
>>> are not part of CDS). Right?
>>
>> The InstanceKlass has offsets to fields in the instance, and they depend
>> on both compressed oops and compressed klass pointers.   So both have to
>> be on for the offsets to be valid.
>>
>> But the base and compressed values are not stored anywhere in the CDS
>> archive.
>>
>>> And you don't care about UseCompressedOops and
>>> UseCompressedKlassPointers flags settings when you dump it into
>>> archive. The only limit is:
>>>
>>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total
>>>
>>> Then I don't understand why you can't use/load CDS archive when coop
>>> or compklass are off:
>>>
>>> > If coop is turned off then CDS cannot be used.  CDS will only be
>>> > supported if both UseCompressedOops and UseCompressedKlassPointers 
>>> are
>>> > TRUE.
>>>
>>> Also based on code in arguments.cpp it is allowed to specify
>>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command line:
>>>
>>> 1466     // Turn on UseCompressedKlassPointers too
>>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>>> 1469     }
>>>
>>> Did you tested such combination?
>>
>> I should let Harold answer this but I believe this is what his test
>> does.  For CDS on 64 bit, both must be on.   We didn't want to create 4
>> different archives.   And it wouldn't make too much sense since CDS for
>> 64 bit is a footprint savings so why would you use it without
>> compressing oops and class pointers?  It's not a startup savings on
>> server because we turn off interpreter bytecode quickening.
>>
>> Coleen
>>
>>>
>>>>>
>>>>> set_narrow_klass_base_and_shift() and
>>>>> can_use_cds_with_metaspace_addr() have the same code for
>>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>>>> can_use_cds_with_metaspace_addr() from
>>>>> set_narrow_klass_base_and_shift() ?
>>>> I could add new inlined methods that determine the higher_address and
>>>> lower_base when UseSharedSpaces is true and have them called from
>>>> set_narrow_klass_base_and_shift() and
>>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>>>
>>> I tried several approaches but your implementation is more clean. So I
>>> agree to keep what you have now.
>>>
>>>
>>> Also I found strange assert which should always fail (old code in
>>> global_initialize() in metaspace.cpp):
>>>
>>> 2959     if (UseSharedSpaces) {
>>> ...
>>> 2969       } else {
>>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>>> 2971                "archive file not closed or shared spaces not
>>> disabled.");
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>>
>>>>> I see that you unconditionally set comp klass ptr base and shift for
>>>>> DumpSharedSpaces. Should you do the check similar to
>>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>>>>> don't even check UseCompressedKlassPointers.
>>>> I don't think the checks are needed because the information written to
>>>> the archive is not affected by the size of the class metaspace.
>>>>
>>>> Also, I recently added code to arguments.cpp that will generate an 
>>>> error
>>>> if UseCompressedOops or UseCompressedKlassPointers is turned off and
>>>> DumpSharedSpaces is on.
>>>>>
>>>>> Why you have next limitation? What if coop can't be used because of
>>>>> big heap?:
>>>>>
>>>>> +     // UseCompressedOops and UseCompressedKlassPointers must be on
>>>>> for UseSharedSpaces.
>>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>> +       no_shared_spaces();
>>>> If coop is turned off then CDS cannot be used.  CDS will only be
>>>> supported if both UseCompressedOops and UseCompressedKlassPointers are
>>>> TRUE.
>>>>>
>>>>> Could you move UseCompressedKlassPointers code in arguments.cpp into
>>>>> separate method similar to set_use_compressed_oops()?
>>>> Done.
>>>>>
>>>>> About new tests.
>>>>> The first test in CDSCompressedKPtrsError misses
>>>>> -XX:+UseCompressedOops flag.
>>>> Fixed.
>>>>>
>>>>> Could you also test cross flags combinations?:
>>>>>
>>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>>> Done.
>>>>>
>>>>> It would be nice to have test to check ClassMetaspaceSize value 
>>>>> range.
>>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint
>>>>> or maxuint.
>>>> A member of our runtime SQE group is writing additional tests. I'll 
>>>> ask
>>>> him to write a ClassMetaspaceSize range test.
>>>>
>>>> We chose 3Gb because we thought it was a sufficiently large size.
>>>>>
>>>>>
>>>>> About code style, indention. We align next line to corresponding part
>>>>> of previous line if we need to split a line. And sometimes it is
>>>>> better to keep one long line. I understand some of them were before
>>>>> your changes but, please, clean up at lest ones you touched.
>>>> Done.
>>>>>
>>>>> Cases in metaspace.cpp:
>>>>>
>>>>> 2263   assert(raw_word_size >= min_size,
>>>>> 2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<"
>>>>> SIZE_FORMAT, word_size, min_size));
>>>>>
>>>>>
>>>>> 2485   if (Metaspace::using_class_space() &&
>>>>> 2486     (Metaspace::class_space_list() != NULL)) {
>>>>>
>>>>>
>>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>>>> 2575                       (Metaspace::using_class_space() ?
>>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>>>
>>>>>
>>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>>>> SIZE_FORMAT ", "
>>>>> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT
>>>>> ", "
>>>>> 2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>>>> ", "
>>>>> 2697                            "large count " SIZE_FORMAT,
>>>>> 2698              cls_specialized_count, cls_specialized_waste,
>>>>> 2699              cls_small_count, cls_small_waste,
>>>>> 2700              cls_medium_count, cls_medium_waste,
>>>>> cls_humongous_count);
>>>>>
>>>>>
>>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G > 
>>>>> addr) &&
>>>>> 2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>>>
>>>>>
>>>>> 2889         vm_exit_during_initialization(err_msg(
>>>>> 2890           "Could not allocate metaspace: %d bytes",
>>>>> 2891           class_metaspace_size()));
>>>>>
>>>>>
>>>>> 3107     return using_class_space() ?
>>>>> 3108       class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>>>
>>>>>
>>>>> 3157     if (is_class && using_class_space()) {
>>>>> 3158        class_vsm()->deallocate(ptr, word_size);
>>>>>
>>>>>
>>>>> 3305   return space_list()->contains(ptr) ||
>>>>> 3306     (using_class_space() && class_space_list()->contains(ptr));
>>>>>
>>>>> metaspace.hpp:
>>>>>
>>>>>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
>>>>>  271       (Metaspace::using_class_space() ?
>>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>>>
>>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>>>>>  286       (Metaspace::using_class_space() ?
>>>>>  287         _allocated_used_words[Metaspace::ClassType] : 0);
>>>>>
>>>>> universe.cpp:
>>>>>
>>>>>  849   assert((intptr_t)Universe::narrow_oop_base() <=
>>>>> (intptr_t)(Universe::heap()->base() -
>>>>>  850     os::vm_page_size()) ||
>>>>>  851            Universe::narrow_oop_base() == NULL, "invalid 
>>>>> value");
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this updated webrev for bug 8003424:
>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>>>
>>>>>> The updated webrev has a lot of changes from the previous webrev,
>>>>>> including the following:
>>>>>>
>>>>>>     1. Class metaspace information is now output when
>>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>>>>
>>>>>>     2. decode_klass_not_null(Register dst, Register src) no longer
>>>>>>     clobbers R12.
>>>>>>
>>>>>>     3. Method using_class_vsm() was renamed to using_class_space().
>>>>>>
>>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>>>>>> appropriate.
>>>>>>
>>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>>>>> unnecessary.
>>>>>>
>>>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>>>
>>>>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>>>>>> updated.
>>>>>>
>>>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005,
>>>>>> and
>>>>>> specjbb2013.  The results showed no significant performance 
>>>>>> difference
>>>>>> in terms of scores and gc behavior.
>>>>>>
>>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>>>>>
>>>>>> Please let me know what additional tests should be run.
>>>>>>
>>>>>> Thanks!
>>>>>> Harold
>>>>>>
>>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>>>> Hi Harold,
>>>>>>>
>>>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which 
>>>>>>> means
>>>>>>> that
>>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>>>> unless
>>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>>>> make
>>>>>>> sense?
>>>>>>>
>>>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000
>>>>>>> and I
>>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>>>>>> (assuming or
>>>>>>> with check that class metaspace size < 32Gb).
>>>>>>>
>>>>>>> > Is there one prefix byte per instruction, or just for certain
>>>>>>> instructions?
>>>>>>>
>>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>>>>>> prefix is
>>>>>>> necessary only if an instruction references one of the extended
>>>>>>> registers or uses a 64-bit operand."
>>>>>>>
>>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and 
>>>>>>> =32
>>>>>>> and big java heap. Recently we got several bugs which indicated 
>>>>>>> that
>>>>>>> we did not separate cleanly oops and klass pointers en/decoding.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>>>>> Hi Vladimir,
>>>>>>>>
>>>>>>>> Thank you for the review!  Please see inline comments.
>>>>>>>>
>>>>>>>> Thanks, Harold
>>>>>>>>
>>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>>>>>> Nice clean up, Harold
>>>>>>>>>>
>>>>>>>>>> Could you add the size of class metaspace in output with
>>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>>>>>>>> remember an
>>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>>>>>> Will be done in next webrev.
>>>>>>>>>>
>>>>>>>>>> Also it would be nice to print these info line (and compressed
>>>>>>>>>> oops
>>>>>>>>>> info
>>>>>>>>>> line) in hs_err files.
>>>>>>>> I filed an enhancement bug for this: 8021264
>>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>>>>>>
>>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>>>>>>>>>> x86_64.ad.
>>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use 
>>>>>>>>>> arithmetic
>>>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also
>>>>>>>>>> note
>>>>>>>>>> that code in .ad file does not check the encoding mode for 
>>>>>>>>>> narrow
>>>>>>>>>> klass/oop so it should be conservative and assume that 
>>>>>>>>>> arithmetic
>>>>>>>>>> instructions are used.
>>>>>>>> OK. Thanks.
>>>>>>>>>>
>>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>>>>>>>>>> 4Gb so
>>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>>>>>> encoding/decoding without destroying R12.
>>>>>>>>>
>>>>>>>>> Correction. You can do it only if base < 2Gb max positive int 
>>>>>>>>> (sign
>>>>>>>>> bit is extended so you will get wrong result with address > 2gb).
>>>>>>>> But the base will normally be 32Gb.  So this case won't happen 
>>>>>>>> very
>>>>>>>> often.
>>>>>>>>>
>>>>>>>>> You definitely should not use R12 in 
>>>>>>>>> decode_klass_not_null(Register
>>>>>>>>> dst, Register src) method where you have free 'dst' register.
>>>>>>>> Will be fixed in next webrev.
>>>>>>>>>
>>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 
>>>>>>>>> 64Gb.
>>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>>>>>
>>>>>>>>> decode:
>>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>>>>>   }
>>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= 
>>>>>>>>> maxint
>>>>>>>>> (max positive int).
>>>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>>>>>>>> that
>>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>>>>>>>> unless
>>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>>>>> make
>>>>>>>> sense?
>>>>>>>>>
>>>>>>>>> And you have general memory reservation problem. At least on
>>>>>>>>> Solaris,
>>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
>>>>>>>>> between
>>>>>>>>> different requested memory regions. That is why in jdk7 we first
>>>>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>>>>>>>>> protection page below heap to catch implicit NULL exceptions with
>>>>>>>>> compressed oops.
>>>>>>>>>
>>>>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>>>>>>> compressed
>>>>>>>>> oops and with Xmx20Gb.
>>>>>>>> I verifed that we get either cds_address+cds_total as the
>>>>>>>> address, or
>>>>>>>> CompressedKlassPointersBase as the address without CDS on Linux,
>>>>>>>> Windows
>>>>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap
>>>>>>>> sizes and
>>>>>>>> -Xmx32G.
>>>>>>>>
>>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the
>>>>>>>> desired
>>>>>>>> CDS address for class metaspace regardless of heap size.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>>>>>>>>> unfortunately we
>>>>>>>>>> can't do other way. I assume you use max size because 
>>>>>>>>>> depending on
>>>>>>>>>> registers used in instructions you will or will not get prefix
>>>>>>>>>> byte
>>>>>>>>>> (r8-r15).
>>>>>>>> Is there one prefix byte per instruction, or just for certain
>>>>>>>> instructions?
>>>>>>>>>>
>>>>>>>>>> I will look on changes in more details may be late.
>>>>>>>>>
>>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use 
>>>>>>>>> abbreviations
>>>>>>>>> which are not obvious.
>>>>>>>> I changed using_class_vsm() to using_class_space().
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Please review this fix for bug 8003424.
>>>>>>>>>>>
>>>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>>>>>>> Open bug links at:
>>>>>>>>>>>
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>>>>>>>
>>>>>>>>>>> JBS Bug links at
>>>>>>>>>>>
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This fix provides support for using compressed klass pointers
>>>>>>>>>>> with
>>>>>>>>>>> CDS.
>>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>>>>>>>>>> platforms
>>>>>>>>>>> when
>>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the
>>>>>>>>>>> class
>>>>>>>>>>> metaspace as part of the Java Heap allocation and locating 
>>>>>>>>>>> it at
>>>>>>>>>>> the
>>>>>>>>>>> base of that allocation, the metaspace will now be allocated
>>>>>>>>>>> separately,
>>>>>>>>>>> above the Java heap.  This will enable future expansion of the
>>>>>>>>>>> metaspace
>>>>>>>>>>> because it won't be backed up against the Java heap. If CDS is
>>>>>>>>>>> being
>>>>>>>>>>> used, then the CDS region will be allocated between the Java
>>>>>>>>>>> heap and
>>>>>>>>>>> the metaspace.
>>>>>>>>>>>
>>>>>>>>>>> The new class metaspace allocation code tries to allocate
>>>>>>>>>>> memory at
>>>>>>>>>>> 32G,
>>>>>>>>>>> or above the CDS region, if it is present. Because of this,
>>>>>>>>>>> encoding
>>>>>>>>>>> and decoding of compressed klass pointers will always 
>>>>>>>>>>> require use
>>>>>>>>>>> of a
>>>>>>>>>>> base register.  So, encoding and decoding of compressed klass
>>>>>>>>>>> pointers
>>>>>>>>>>> will differ from compressed oops.
>>>>>>>>>>>
>>>>>>>>>>> There are no class metaspace allocation changes if
>>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
>>>>>>>>>>> 32-bit
>>>>>>>>>>> platform.
>>>>>>>>>>>
>>>>>>>>>>> The code changes also include some cleanup and will fix bugs
>>>>>>>>>>> 8016729,
>>>>>>>>>>> 8011610, and 8003424.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Many of the modules in this webrev contain a lot of changes.
>>>>>>>>>>> Modules
>>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>>>>>>>>>> changed to
>>>>>>>>>>> support the new encoding and decoding of compressed klass
>>>>>>>>>>> pointers.
>>>>>>>>>>>
>>>>>>>>>>> Module metaspace.cpp was changed significantly to support 
>>>>>>>>>>> the new
>>>>>>>>>>> allocation for metaspace and the CDS region and to determine
>>>>>>>>>>> compressed
>>>>>>>>>>> klass pointer encoding base and shifting values.
>>>>>>>>>>>
>>>>>>>>>>> Most of the changes to module universe.cpp were to remove code
>>>>>>>>>>> related
>>>>>>>>>>> to allocating metaspace and remove code that considered
>>>>>>>>>>> compressed
>>>>>>>>>>> klass
>>>>>>>>>>> pointers when determining the compressed oops compression
>>>>>>>>>>> mechanism.
>>>>>>>>>>>
>>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as 
>>>>>>>>>>> part
>>>>>>>>>>> of a
>>>>>>>>>>> cleanup requested by Coleen.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
>>>>>>>>>>> tests,
>>>>>>>>>>> JPRT,
>>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and 
>>>>>>>>>>> vm.mlvm.testlist
>>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and 
>>>>>>>>>>> -Xshare:off
>>>>>>>>>>> (with
>>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit 
>>>>>>>>>>> Linux and
>>>>>>>>>>> 64-Bit
>>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests
>>>>>>>>>>> were
>>>>>>>>>>> run on Solaris x86.
>>>>>>>>>>>
>>>>>>>>>>> The performance impact of these changes is TBD.
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Harold
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>


From yumin.qi at oracle.com  Fri Aug  9 06:52:19 2013
From: yumin.qi at oracle.com (yumin.qi at oracle.com)
Date: Fri, 09 Aug 2013 13:52:19 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130809135229.C27824874D@hg.openjdk.java.net>

Changeset: 57ac7245594c
Author:    minqi
Date:      2013-08-08 15:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/57ac7245594c

8019583: [TESTBUG] runtime/7107135 always passes
Summary: If java test return none zero, the value will be override by 'if' statement, the exit value will always '0' and pass. Fix by recording the result in a variable.
Reviewed-by: coleenp, dholmes, iklam
Contributed-by: yumin.qi at oracle.com

! test/runtime/7107135/Test7107135.sh

Changeset: 6222a021d582
Author:    minqi
Date:      2013-08-08 20:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6222a021d582

Merge



From harold.seigel at oracle.com  Fri Aug  9 07:57:29 2013
From: harold.seigel at oracle.com (Harold Seigel)
Date: Fri, 9 Aug 2013 07:57:29 -0700 (PDT)
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
Message-ID: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>

Hi, 

Please review this latest version of the bug fix for 8003424:? http://cr.openjdk.java.net/~hseigel/bug_8003424.3/ 


This new version?includes the following changes: 

1. macroAssembler_sparc.cpp 

?? a. Merged two versions of reinit_heapbase() into one. 

?? b. Improved decode_klass_not_null(src, dst) to not use G6 if shift == 0. 


2. macroAssembler_x86.cpp 

?? a. Merged two versions of reinit_heapbase() into one. 

?? b. Improved encode_klass_not_null(src, dst) to not use R12. 

?? c. Replaced leaq with addq in decode_klass_not_null(src, dst). 


3. Improved variable names in heap.cpp. 


4. metaspace.cpp 

?? a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more understandable. 

?? b. Moved set_narrow_klass_base_and_shift() near can_use_cds_with_metaspace_addr(). 

?? c. Changed unneeded conditional in initialize_class_space() into an assert. 


5. arguments.cpp 

?? a. Fixed problem with -Xshare:dump and disabled compression. 

?? b. Moved UseCompressedKlassPointers code into new function: set_use_compressed_klass_ptrs(). 

?? c. Fixed bug 8005933 that turned off CDS for -server even if -Xshare:auto was explicitly specified. 


6. Increased default value of ClassMetaspaceSize to 1*G in globals.hpp. 


7. Fixed indentation issues in metaspace.cpp and other modules. 


Thanks, Harold 

----- Original Message ----- 
From: harold.seigel at oracle.com 
To: coleen.phillimore at oracle.com 
Cc: hotspot-runtime-dev at openjdk.java.net 
Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern 
Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for CompressedOops 

The purpose of this assert is to verify that the two methods in the 'if' clause closed the map file and disabled UseSharedSpaces if they detected a problem when trying to use CDS. ? 

?? ? ?if (mapinfo->initialize() && MetaspaceShared::map_shared_spaces(mapinfo)) { 
?? ? ? ?FileMapInfo::set_current_info(mapinfo); 
?? ? ?} else { 
?? ? ? ?assert(!mapinfo->is_open() && !UseSharedSpaces, 
?? ? ? ? ? ? ? "archive file not closed or shared spaces not disabled."); 
?? ? ?} 

----- Original Message ----- 
From: harold.seigel at oracle.com 
To: coleen.phillimore at oracle.com 
Cc: hotspot-runtime-dev at openjdk.java.net 
Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern 
Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for CompressedOops 

This is a bug that Stefan Karlsson also discovered. ?To fix it, I've changed the code to this: 

??if (DumpSharedSpaces) { 
?? ?if (RequireSharedSpaces) { 
?? ? ?warning("cannot dump shared archive while using shared archive"); 
?? ?} 
?? ?UseSharedSpaces = false; 
#ifdef _LP64 
?? ?if (!UseCompressedOops || !UseCompressedKlassPointers) { 
?? ? ?vm_exit_during_initialization( 
?? ? ? ?"Cannot dump shared archive when UseCompressedOops or UseCompressedKlassPointers is off.", NULL); 
?? ?} 

Harold 


----- Original Message ----- 
From: coleen.phillimore at oracle.com 
To: hotspot-runtime-dev at openjdk.java.net 
Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern 
Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for CompressedOops 


Yes, there should be a check for that too. ?Now I'll really let Harold 
answer. 

Thanks, 
Coleen 

On 08/08/2013 06:55 PM, Vladimir Kozlov wrote: 
> Coleen, Harold 
> 
> > The InstanceKlass has offsets to fields in the instance, and they 
> depend 
> > on both compressed oops and compressed klass pointers. ? So both 
> have to 
> > be on for the offsets to be valid. 
> 
> So there is dependency on UseCompressedOops and 
> UseCompressedKlassPointers flags during dump. 
> 
> Then why the check is done only for UseSharedSpaces and not for 
> DumpSharedSpaces?: 
> 
> ? ? if (DumpSharedSpaces) { 
> ? ? ? if (RequireSharedSpaces) { 
> ? ? ? ? warning("cannot dump shared archive while using shared archive"); 
> ? ? ? } 
> ? ? ? UseSharedSpaces = false; 
> + #ifdef _LP64 
> + ? } else { 
> + ? ? // UseCompressedOops and UseCompressedKlassPointers must be on 
> for UseSharedSpaces. 
> + ? ? if (!UseCompressedOops || !UseCompressedKlassPointers) { 
> + ? ? ? no_shared_spaces(); 
> + ? ? } 
> + #endif 
> ? ? } 
> 
> Thanks, 
> Vladimir 
> 
> On 8/8/13 3:34 PM, Coleen Phillimore wrote: 
>> 
>> Hi Vladimir, 
>> 
>> I have a couple of answers and I'll let Harold answer the rest. 
>> 
>> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote: 
>>> On 8/7/13 8:34 AM, harold seigel wrote: 
>>>> Hi Vladimir, 
>>>> 
>>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote: 
>>>>> Harold, 
>>>>> 
>>>>> Note, on SPARC set() could generate up to 8 instructions to load 
>>>>> 64-bit constant into register. So I am not sure that it will be 
>>>>> faster 
>>>>> than load. 
>>>> We thought it would be faster because it doesn't need to load anything 
>>>> from memory. 
>>> 
>>> For good value (0x800000000) it should use only 2-3 instructions. 
>>> I think you can keep using set(). 
>>> 
>>>>> 
>>>>> I can't find where in CDS you store information about compressed 
>>>>> klass 
>>>>> pointers and compressed oops parameters which were used during dump? 
>>>>> How you verify that correct parameters/flags are ussed when such CDS 
>>>>> is used later? 
>>>> No compressed klass pointers nor compressed oops get written to the 
>>>> archive. ?So, the compressed klass pointers and compressed oops 
>>>> parameters do not need to be recorded in the archive. 
>>> 
>>> So you are saying that all klass pointers (references to klasses) in 
>>> metadata structures in metaspace are full. 
>> 
>> Yes, they are. ?(methodOops weren't in the InstanceKlass::_methods array 
>> with Permgen but they are uncompressed now). 
>> 
>>> And klass pointers are only compressed in java object headers (which 
>>> are not part of CDS). Right? 
>> 
>> The InstanceKlass has offsets to fields in the instance, and they depend 
>> on both compressed oops and compressed klass pointers. ? So both have to 
>> be on for the offsets to be valid. 
>> 
>> But the base and compressed values are not stored anywhere in the CDS 
>> archive. 
>> 
>>> And you don't care about UseCompressedOops and 
>>> UseCompressedKlassPointers flags settings when you dump it into 
>>> archive. The only limit is: 
>>> 
>>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total 
>>> 
>>> Then I don't understand why you can't use/load CDS archive when coop 
>>> or compklass are off: 
>>> 
>>> > If coop is turned off then CDS cannot be used. ?CDS will only be 
>>> > supported if both UseCompressedOops and UseCompressedKlassPointers 
>>> are 
>>> > TRUE. 
>>> 
>>> Also based on code in arguments.cpp it is allowed to specify 
>>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command line: 
>>> 
>>> 1466 ? ? // Turn on UseCompressedKlassPointers too 
>>> 1467 ? ? if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) { 
>>> 1468 ? ? ? FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true); 
>>> 1469 ? ? } 
>>> 
>>> Did you tested such combination? 
>> 
>> I should let Harold answer this but I believe this is what his test 
>> does. ?For CDS on 64 bit, both must be on. ? We didn't want to create 4 
>> different archives. ? And it wouldn't make too much sense since CDS for 
>> 64 bit is a footprint savings so why would you use it without 
>> compressing oops and class pointers? ?It's not a startup savings on 
>> server because we turn off interpreter bytecode quickening. 
>> 
>> Coleen 
>> 
>>> 
>>>>> 
>>>>> set_narrow_klass_base_and_shift() and 
>>>>> can_use_cds_with_metaspace_addr() have the same code for 
>>>>> UseSharedSpaces. It would be nice to have only one copy. Call 
>>>>> can_use_cds_with_metaspace_addr() from 
>>>>> set_narrow_klass_base_and_shift() ? 
>>>> I could add new inlined methods that determine the higher_address and 
>>>> lower_base when UseSharedSpaces is true and have them called from 
>>>> set_narrow_klass_base_and_shift() and 
>>>> can_use_cds_with_metaspace_addr(). ?Would that be worth doing? 
>>> 
>>> I tried several approaches but your implementation is more clean. So I 
>>> agree to keep what you have now. 
>>> 
>>> 
>>> Also I found strange assert which should always fail (old code in 
>>> global_initialize() in metaspace.cpp): 
>>> 
>>> 2959 ? ? if (UseSharedSpaces) { 
>>> ... 
>>> 2969 ? ? ? } else { 
>>> 2970 ? ? ? ? assert(!mapinfo->is_open() && !UseSharedSpaces, 
>>> 2971 ? ? ? ? ? ? ? ?"archive file not closed or shared spaces not 
>>> disabled."); 
>>> 
>>> Thanks, 
>>> Vladimir 
>>> 
>>>>> 
>>>>> I see that you unconditionally set comp klass ptr base and shift for 
>>>>> DumpSharedSpaces. Should you do the check similar to 
>>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You 
>>>>> don't even check UseCompressedKlassPointers. 
>>>> I don't think the checks are needed because the information written to 
>>>> the archive is not affected by the size of the class metaspace. 
>>>> 
>>>> Also, I recently added code to arguments.cpp that will generate an 
>>>> error 
>>>> if UseCompressedOops or UseCompressedKlassPointers is turned off and 
>>>> DumpSharedSpaces is on. 
>>>>> 
>>>>> Why you have next limitation? What if coop can't be used because of 
>>>>> big heap?: 
>>>>> 
>>>>> + ? ? // UseCompressedOops and UseCompressedKlassPointers must be on 
>>>>> for UseSharedSpaces. 
>>>>> + ? ? if (!UseCompressedOops || !UseCompressedKlassPointers) { 
>>>>> + ? ? ? no_shared_spaces(); 
>>>> If coop is turned off then CDS cannot be used. ?CDS will only be 
>>>> supported if both UseCompressedOops and UseCompressedKlassPointers are 
>>>> TRUE. 
>>>>> 
>>>>> Could you move UseCompressedKlassPointers code in arguments.cpp into 
>>>>> separate method similar to set_use_compressed_oops()? 
>>>> Done. 
>>>>> 
>>>>> About new tests. 
>>>>> The first test in CDSCompressedKPtrsError misses 
>>>>> -XX:+UseCompressedOops flag. 
>>>> Fixed. 
>>>>> 
>>>>> Could you also test cross flags combinations?: 
>>>>> 
>>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops 
>>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops 
>>>> Done. 
>>>>> 
>>>>> It would be nice to have test to check ClassMetaspaceSize value 
>>>>> range. 
>>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint 
>>>>> or maxuint. 
>>>> A member of our runtime SQE group is writing additional tests. I'll 
>>>> ask 
>>>> him to write a ClassMetaspaceSize range test. 
>>>> 
>>>> We chose 3Gb because we thought it was a sufficiently large size. 
>>>>> 
>>>>> 
>>>>> About code style, indention. We align next line to corresponding part 
>>>>> of previous line if we need to split a line. And sometimes it is 
>>>>> better to keep one long line. I understand some of them were before 
>>>>> your changes but, please, clean up at lest ones you touched. 
>>>> Done. 
>>>>> 
>>>>> Cases in metaspace.cpp: 
>>>>> 
>>>>> 2263 ? assert(raw_word_size >= min_size, 
>>>>> 2264 ? ? err_msg("Should not deallocate dark matter " SIZE_FORMAT "<" 
>>>>> SIZE_FORMAT, word_size, min_size)); 
>>>>> 
>>>>> 
>>>>> 2485 ? if (Metaspace::using_class_space() && 
>>>>> 2486 ? ? (Metaspace::class_space_list() != NULL)) { 
>>>>> 
>>>>> 
>>>>> 2574 ? size_t reserved = (mdtype == Metaspace::ClassType) ? 
>>>>> 2575 ? ? ? ? ? ? ? ? ? ? ? (Metaspace::using_class_space() ? 
>>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) : 
>>>>> 2577 Metaspace::space_list()->virtual_space_total(); 
>>>>> 
>>>>> 
>>>>> 2694 ? out->print_cr(" class: " SIZE_FORMAT " specialized(s) " 
>>>>> SIZE_FORMAT ", " 
>>>>> 2695 ? ? ? ? ? ? ? ? ? ? ? ? ? ?SIZE_FORMAT " small(s) " SIZE_FORMAT 
>>>>> ", " 
>>>>> 2696 ? ? ? ? ? ? ? ? ? ? ? ? ? ?SIZE_FORMAT " medium(s) " SIZE_FORMAT 
>>>>> ", " 
>>>>> 2697 ? ? ? ? ? ? ? ? ? ? ? ? ? ?"large count " SIZE_FORMAT, 
>>>>> 2698 ? ? ? ? ? ? ?cls_specialized_count, cls_specialized_waste, 
>>>>> 2699 ? ? ? ? ? ? ?cls_small_count, cls_small_waste, 
>>>>> 2700 ? ? ? ? ? ? ?cls_medium_count, cls_medium_waste, 
>>>>> cls_humongous_count); 
>>>>> 
>>>>> 
>>>>> 2872 ? ? ? while (!metaspace_rs.is_reserved() && (addr + 1*G > 
>>>>> addr) && 
>>>>> 2873 ? ? ? ? can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) { 
>>>>> 
>>>>> 
>>>>> 2889 ? ? ? ? vm_exit_during_initialization(err_msg( 
>>>>> 2890 ? ? ? ? ? "Could not allocate metaspace: %d bytes", 
>>>>> 2891 ? ? ? ? ? class_metaspace_size())); 
>>>>> 
>>>>> 
>>>>> 3107 ? ? return using_class_space() ? 
>>>>> 3108 ? ? ? class_vsm()->sum_used_in_chunks_in_use() : 0; 
>>>>> 
>>>>> 
>>>>> 3157 ? ? if (is_class && using_class_space()) { 
>>>>> 3158 ? ? ? ?class_vsm()->deallocate(ptr, word_size); 
>>>>> 
>>>>> 
>>>>> 3305 ? return space_list()->contains(ptr) || 
>>>>> 3306 ? ? (using_class_space() && class_space_list()->contains(ptr)); 
>>>>> 
>>>>> metaspace.hpp: 
>>>>> 
>>>>> ?270 ? ? return _allocated_capacity_words[Metaspace::NonClassType] + 
>>>>> ?271 ? ? ? (Metaspace::using_class_space() ? 
>>>>> ?272 _allocated_capacity_words[Metaspace::ClassType] : 0); 
>>>>> 
>>>>> ?285 ? ? return _allocated_used_words[Metaspace::NonClassType] + 
>>>>> ?286 ? ? ? (Metaspace::using_class_space() ? 
>>>>> ?287 ? ? ? ? _allocated_used_words[Metaspace::ClassType] : 0); 
>>>>> 
>>>>> universe.cpp: 
>>>>> 
>>>>> ?849 ? assert((intptr_t)Universe::narrow_oop_base() <= 
>>>>> (intptr_t)(Universe::heap()->base() - 
>>>>> ?850 ? ? os::vm_page_size()) || 
>>>>> ?851 ? ? ? ? ? ?Universe::narrow_oop_base() == NULL, "invalid 
>>>>> value"); 
>>>>> 
>>>>> 
>>>>> Thanks, 
>>>>> Vladimir 
>>>>> 
>>>>> On 8/2/13 1:31 PM, harold seigel wrote: 
>>>>>> Hi, 
>>>>>> 
>>>>>> Please review this updated webrev for bug 8003424: 
>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/ 
>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/> 
>>>>>> 
>>>>>> The updated webrev has a lot of changes from the previous webrev, 
>>>>>> including the following: 
>>>>>> 
>>>>>> ? ? 1. Class metaspace information is now output when 
>>>>>> ? ? -XX:+PrintCompressedOopsMode is specified. 
>>>>>> 
>>>>>> ? ? 2. decode_klass_not_null(Register dst, Register src) no longer 
>>>>>> ? ? clobbers R12. 
>>>>>> 
>>>>>> ? ? 3. Method using_class_vsm() was renamed to using_class_space(). 
>>>>>> 
>>>>>> ? ? 4. Type narrowKlass was added and replaces narrowOop, where 
>>>>>> appropriate. 
>>>>>> 
>>>>>> ? ? 5. The Metaspace:: qualifier was removed, where it was 
>>>>>> unnecessary. 
>>>>>> 
>>>>>> ? ? 6. Metaspace::initialize_class_space() was made private. 
>>>>>> 
>>>>>> ? ? 7. Method max_heap_for_compressed_oops(), in arguments.cpp, was 
>>>>>> updated. 
>>>>>> 
>>>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005, 
>>>>>> and 
>>>>>> specjbb2013. ?The results showed no significant performance 
>>>>>> difference 
>>>>>> in terms of scores and gc behavior. 
>>>>>> 
>>>>>> Additional testing was done on Solaris Sparc and Linux x86 using 
>>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32. 
>>>>>> 
>>>>>> Please let me know what additional tests should be run. 
>>>>>> 
>>>>>> Thanks! 
>>>>>> Harold 
>>>>>> 
>>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote: 
>>>>>>> Hi Harold, 
>>>>>>> 
>>>>>>> > Usually the narrow_klass_base will be 32G and the 
>>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which 
>>>>>>> means 
>>>>>>> that 
>>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12, 
>>>>>>> unless 
>>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>>>> make 
>>>>>>> sense? 
>>>>>>> 
>>>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000 
>>>>>>> and I 
>>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage 
>>>>>>> (assuming or 
>>>>>>> with check that class metaspace size < 32Gb). 
>>>>>>> 
>>>>>>> > Is there one prefix byte per instruction, or just for certain 
>>>>>>> instructions? 
>>>>>>> 
>>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A 
>>>>>>> prefix is 
>>>>>>> necessary only if an instruction references one of the extended 
>>>>>>> registers or uses a 64-bit operand." 
>>>>>>> 
>>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and 
>>>>>>> =32 
>>>>>>> and big java heap. Recently we got several bugs which indicated 
>>>>>>> that 
>>>>>>> we did not separate cleanly oops and klass pointers en/decoding. 
>>>>>>> 
>>>>>>> Thanks, 
>>>>>>> Vladimir 
>>>>>>> 
>>>>>>> On 7/24/13 11:35 AM, harold seigel wrote: 
>>>>>>>> Hi Vladimir, 
>>>>>>>> 
>>>>>>>> Thank you for the review! ?Please see inline comments. 
>>>>>>>> 
>>>>>>>> Thanks, Harold 
>>>>>>>> 
>>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote: 
>>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote: 
>>>>>>>>>> Nice clean up, Harold 
>>>>>>>>>> 
>>>>>>>>>> Could you add the size of class metaspace in output with 
>>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to 
>>>>>>>>>> remember an 
>>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation. 
>>>>>>>> Will be done in next webrev. 
>>>>>>>>>> 
>>>>>>>>>> Also it would be nice to print these info line (and compressed 
>>>>>>>>>> oops 
>>>>>>>>>> info 
>>>>>>>>>> line) in hs_err files. 
>>>>>>>> I filed an enhancement bug for this: 8021264 
>>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>. 
>>>>>>>>>> 
>>>>>>>>>> About "effect(KILL cr); ? /// ???? is this KILL needed?" in 
>>>>>>>>>> x86_64.ad. 
>>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use 
>>>>>>>>>> arithmetic 
>>>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also 
>>>>>>>>>> note 
>>>>>>>>>> that code in .ad file does not check the encoding mode for 
>>>>>>>>>> narrow 
>>>>>>>>>> klass/oop so it should be conservative and assume that 
>>>>>>>>>> arithmetic 
>>>>>>>>>> instructions are used. 
>>>>>>>> OK. Thanks. 
>>>>>>>>>> 
>>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below 
>>>>>>>>>> 4Gb so 
>>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass 
>>>>>>>>>> encoding/decoding without destroying R12. 
>>>>>>>>> 
>>>>>>>>> Correction. You can do it only if base < 2Gb max positive int 
>>>>>>>>> (sign 
>>>>>>>>> bit is extended so you will get wrong result with address > 2gb). 
>>>>>>>> But the base will normally be 32Gb. ?So this case won't happen 
>>>>>>>> very 
>>>>>>>> often. 
>>>>>>>>> 
>>>>>>>>> You definitely should not use R12 in 
>>>>>>>>> decode_klass_not_null(Register 
>>>>>>>>> dst, Register src) method where you have free 'dst' register. 
>>>>>>>> Will be fixed in next webrev. 
>>>>>>>>> 
>>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it 
>>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be 
>>>>>>>>> 64Gb. 
>>>>>>>>> The idea was to avoid using R12 by using shifted base: 
>>>>>>>>> 
>>>>>>>>> decode: 
>>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) { 
>>>>>>>>> ? if (Universe::set_narrow_klass_shift() == 0) { 
>>>>>>>>> ? ? shrq(r, LogKlassAlignmentInBytes); 
>>>>>>>>> ? } 
>>>>>>>>> ? addq(r, Universe::narrow_klass_base_shifted()); 
>>>>>>>>> ? shlq(r, LogKlassAlignmentInBytes); 
>>>>>>>>> } 
>>>>>>>>> 
>>>>>>>>> Universe::narrow_klass_base_shifted() is set only if 
>>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <= 
>>>>>>>>> maxint 
>>>>>>>>> (max positive int). 
>>>>>>>> Usually the narrow_klass_base will be 32G and the 
>>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means 
>>>>>>>> that 
>>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12, 
>>>>>>>> unless 
>>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that 
>>>>>>>> make 
>>>>>>>> sense? 
>>>>>>>>> 
>>>>>>>>> And you have general memory reservation problem. At least on 
>>>>>>>>> Solaris, 
>>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages 
>>>>>>>>> between 
>>>>>>>>> different requested memory regions. That is why in jdk7 we first 
>>>>>>>>> reserve one huge space and then cut it on java heap, perm gen and 
>>>>>>>>> protection page below heap to catch implicit NULL exceptions with 
>>>>>>>>> compressed oops. 
>>>>>>>>> 
>>>>>>>>> So, please, verify that you are getting 'cds_address + cds_total' 
>>>>>>>>> address or CompressedKlassPointersBase without CDS and with 
>>>>>>>>> compressed 
>>>>>>>>> oops and with Xmx20Gb. 
>>>>>>>> I verifed that we get either cds_address+cds_total as the 
>>>>>>>> address, or 
>>>>>>>> CompressedKlassPointersBase as the address without CDS on Linux, 
>>>>>>>> Windows 
>>>>>>>> 7, Mac OS, and Solaris 5.11. ?This is true with default heap 
>>>>>>>> sizes and 
>>>>>>>> -Xmx32G. 
>>>>>>>> 
>>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the 
>>>>>>>> desired 
>>>>>>>> CDS address for class metaspace regardless of heap size. 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but 
>>>>>>>>>> unfortunately we 
>>>>>>>>>> can't do other way. I assume you use max size because 
>>>>>>>>>> depending on 
>>>>>>>>>> registers used in instructions you will or will not get prefix 
>>>>>>>>>> byte 
>>>>>>>>>> (r8-r15). 
>>>>>>>> Is there one prefix byte per instruction, or just for certain 
>>>>>>>> instructions? 
>>>>>>>>>> 
>>>>>>>>>> I will look on changes in more details may be late. 
>>>>>>>>> 
>>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use 
>>>>>>>>> abbreviations 
>>>>>>>>> which are not obvious. 
>>>>>>>> I changed using_class_vsm() to using_class_space(). 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Thanks, 
>>>>>>>>>> Vladimir 
>>>>>>>>>> 
>>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote: 
>>>>>>>>>>> Hi, 
>>>>>>>>>>> 
>>>>>>>>>>> Please review this fix for bug 8003424. 
>>>>>>>>>>> 
>>>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/ 
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/> 
>>>>>>>>>>> Open bug links at: 
>>>>>>>>>>> 
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424 
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729 
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610 
>>>>>>>>>>> 
>>>>>>>>>>> JBS Bug links at 
>>>>>>>>>>> 
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424 
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729 
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> This fix provides support for using compressed klass pointers 
>>>>>>>>>>> with 
>>>>>>>>>>> CDS. 
>>>>>>>>>>> It also changes the class metaspace allocation on 64-bit 
>>>>>>>>>>> platforms 
>>>>>>>>>>> when 
>>>>>>>>>>> UseCompressedKlassPointers is true. ?Instead of allocating the 
>>>>>>>>>>> class 
>>>>>>>>>>> metaspace as part of the Java Heap allocation and locating 
>>>>>>>>>>> it at 
>>>>>>>>>>> the 
>>>>>>>>>>> base of that allocation, the metaspace will now be allocated 
>>>>>>>>>>> separately, 
>>>>>>>>>>> above the Java heap. ?This will enable future expansion of the 
>>>>>>>>>>> metaspace 
>>>>>>>>>>> because it won't be backed up against the Java heap. If CDS is 
>>>>>>>>>>> being 
>>>>>>>>>>> used, then the CDS region will be allocated between the Java 
>>>>>>>>>>> heap and 
>>>>>>>>>>> the metaspace. 
>>>>>>>>>>> 
>>>>>>>>>>> The new class metaspace allocation code tries to allocate 
>>>>>>>>>>> memory at 
>>>>>>>>>>> 32G, 
>>>>>>>>>>> or above the CDS region, if it is present. Because of this, 
>>>>>>>>>>> encoding 
>>>>>>>>>>> and decoding of compressed klass pointers will always 
>>>>>>>>>>> require use 
>>>>>>>>>>> of a 
>>>>>>>>>>> base register. ?So, encoding and decoding of compressed klass 
>>>>>>>>>>> pointers 
>>>>>>>>>>> will differ from compressed oops. 
>>>>>>>>>>> 
>>>>>>>>>>> There are no class metaspace allocation changes if 
>>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a 
>>>>>>>>>>> 32-bit 
>>>>>>>>>>> platform. 
>>>>>>>>>>> 
>>>>>>>>>>> The code changes also include some cleanup and will fix bugs 
>>>>>>>>>>> 8016729, 
>>>>>>>>>>> 8011610, and 8003424. 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Many of the modules in this webrev contain a lot of changes. 
>>>>>>>>>>> Modules 
>>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were 
>>>>>>>>>>> changed to 
>>>>>>>>>>> support the new encoding and decoding of compressed klass 
>>>>>>>>>>> pointers. 
>>>>>>>>>>> 
>>>>>>>>>>> Module metaspace.cpp was changed significantly to support 
>>>>>>>>>>> the new 
>>>>>>>>>>> allocation for metaspace and the CDS region and to determine 
>>>>>>>>>>> compressed 
>>>>>>>>>>> klass pointer encoding base and shifting values. 
>>>>>>>>>>> 
>>>>>>>>>>> Most of the changes to module universe.cpp were to remove code 
>>>>>>>>>>> related 
>>>>>>>>>>> to allocating metaspace and remove code that considered 
>>>>>>>>>>> compressed 
>>>>>>>>>>> klass 
>>>>>>>>>>> pointers when determining the compressed oops compression 
>>>>>>>>>>> mechanism. 
>>>>>>>>>>> 
>>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as 
>>>>>>>>>>> part 
>>>>>>>>>>> of a 
>>>>>>>>>>> cleanup requested by Coleen. 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg 
>>>>>>>>>>> tests, 
>>>>>>>>>>> JPRT, 
>>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and 
>>>>>>>>>>> vm.mlvm.testlist 
>>>>>>>>>>> tests. ?Most of the test were run with -Xshare:on and 
>>>>>>>>>>> -Xshare:off 
>>>>>>>>>>> (with 
>>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit 
>>>>>>>>>>> Linux and 
>>>>>>>>>>> 64-Bit 
>>>>>>>>>>> Linux. ?Jtreg tests were run on Windows 7 and Mac OS. JCK tests 
>>>>>>>>>>> were 
>>>>>>>>>>> run on Solaris x86. 
>>>>>>>>>>> 
>>>>>>>>>>> The performance impact of these changes is TBD. 
>>>>>>>>>>> 
>>>>>>>>>>> Thanks, Harold 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/1a31b339/attachment-0001.html 

From mikael.vidstedt at oracle.com  Fri Aug  9 09:18:23 2013
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Fri, 09 Aug 2013 09:18:23 -0700
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <5204CF5E.30705@oracle.com>
References: <5201886C.1030206@oracle.com> <52024E1A.4000908@oracle.com>
	<520275B8.5010101@oracle.com> <52028A69.8010207@oracle.com>
	<52041AC1.4000803@oracle.com> <520430F3.4040306@oracle.com>
	<5204CF5E.30705@oracle.com>
Message-ID: <5205164F.4040607@oracle.com>


The Oracle JDK does not support the older Windows versions in JDK 7. 
However, in an attempt to keep this change small I will keep those 
checks in there and queue up a future cleanup task.

Unless the comment is annoying you all too much I'll keep it in there too.

Cheers,
Mikael

On 2013-08-09 04:15, Dmitry Samersoff wrote:
> Mikael,
>
> Does we still support Win 95/98/Me ?
>
> PS: Comments seems redundant to me
>
> 1660     // find out whether we are running on 64 bit processor or not.
>
> -Dmitry
>
> On 2013-08-09 03:59, Coleen Phillimore wrote:
>> Mikael,
>>
>> I think this looks great.  It's a lot cleaner (more red than blue changes).
>>
>> thanks for humoring me,
>> Coleen
>>
>> On 08/08/2013 06:25 PM, Mikael Vidstedt wrote:
>>> Coleen,
>>>
>>> After having tried numerous different versions I ended up with this:
>>>
>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452.3/webrev
>>>
>>> Summary of the changes:
>>>
>>> * The GetNativeSystemInfo call has been moved up before the switch,
>>> but is only called if the os version is recent enough, and  we
>>> actually care about the si.wProcessorArchitecture field.
>>>
>>> * The true/else branches in the if-diamond have been switch to avoid
>>> the negation of the condition.
>>>
>>> * While at it I added support for recognizing "Windows Server 2008 R2"
>>> (6.1 non-workstation) which we apparently haven't recognized earlier,
>>> but which is something the JDK code recognizes [1].
>>>
>>> * The " , 64 bit" has been move out below the switch, but is only
>>> relevant/tested for on recent enough Windows versions, just like the
>>> old code did.
>>>
>>> Feedback much appreciated! I'm also investigating if it would be
>>> possible to unify/share the code with the java_props_md.c logic [1] to
>>> avoid the duplication, but for now this may have to do. In addition to
>>> that the code can be cleaned up further if we only support VS2010+,
>>> which I believe is de facto since JDK 7 anyway; I will investigate
>>> that as a separate improvement.
>>>
>>> Thanks,
>>> Mikael
>>>
>>> [1]
>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/e057cddf0d6c/src/windows/native/java/lang/java_props_md.c
>>> (line 451).
>>>
>>> On 2013-08-07 10:56, Coleen Phillimore wrote:
>>>> Mikael,
>>>>
>>>> I do like your new version better but because you changed so much, it
>>>> should be verified on all versions of windows.   Which you might not
>>>> want to do.   My suggestion to make this code nicer (fix case stmt
>>>> and outline common code) was really simple and I think can be
>>>> verified by code inspection, which might be less work and easier to
>>>> review.
>>>>
>>>> Coleen
>>>>
>>>> On 8/7/2013 12:28 PM, Mikael Vidstedt wrote:
>>>>> Coleen,
>>>>>
>>>>> Funny you should mention that, and since I fully agree with you I
>>>>> actually did prepare another version of the patch which is heavily
>>>>> inspired by the java_props_md.c implementation:
>>>>>
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/winvercleanup2/webrev/
>>>>>
>>>>> I personally like this version better, but the one thing that held
>>>>> me back was the fact that I will basically want to dig up machines
>>>>> with all the different (supported) Windows versions and verify that
>>>>> the code is still correct in all cases. If you think this is the way
>>>>> to go I more than willing to will do so. Let me know what you think
>>>>> about the new version of the patch!
>>>>>
>>>>> There's no real urgency here - I'd rather do it correct once than...
>>>>>
>>>>> Cheers,
>>>>> Mikael
>>>>>
>>>>>
>>>>> On 2013-08-07 06:39, Coleen Phillimore wrote:
>>>>>> It looks like the code under the case for all these releases,
>>>>>> should be different case statements for each, rather than these
>>>>>> cascading 'if' statements.  And make 1668-1673 a new function
>>>>>> returning si.   So if we have a new release, in general it will
>>>>>> work because the default will print out something.   But a better
>>>>>> default would be lines 1712-1717 which are dead code now.
>>>>>>
>>>>>> Sorry, I know it's simple and urgent but this seems to be getting
>>>>>> increasingly ugly.
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>> On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>>>>>>> Please review the following change:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>>>>>>>
>>>>>>> The patch adds support to os_windows.cpp for recognizing the
>>>>>>> upcoming Windows versions: Windows 8.1 and Windows Server 2012 R2.
>>>>>>>
>>>>>>> The changed is based on the corresponding code on the JDK
>>>>>>> side[1][2][3].
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mikael
>>>>>>>
>>>>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
>>>>>>> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
>>>>>>> [3]
>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>>>>>>>
>>>>>>>
>


From dmitry.samersoff at oracle.com  Fri Aug  9 09:33:02 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 09 Aug 2013 20:33:02 +0400
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <5205164F.4040607@oracle.com>
References: <5201886C.1030206@oracle.com> <52024E1A.4000908@oracle.com>
	<520275B8.5010101@oracle.com> <52028A69.8010207@oracle.com>
	<52041AC1.4000803@oracle.com> <520430F3.4040306@oracle.com>
	<5204CF5E.30705@oracle.com> <5205164F.4040607@oracle.com>
Message-ID: <520519BE.9020805@oracle.com>

Mikael,

Fill free to continue.

Changes looks OK for me.

-Dmitry

On 2013-08-09 20:18, Mikael Vidstedt wrote:
> 
> The Oracle JDK does not support the older Windows versions in JDK 7.
> However, in an attempt to keep this change small I will keep those
> checks in there and queue up a future cleanup task.
> 
> Unless the comment is annoying you all too much I'll keep it in there too.
> 
> Cheers,
> Mikael
> 
> On 2013-08-09 04:15, Dmitry Samersoff wrote:
>> Mikael,
>>
>> Does we still support Win 95/98/Me ?
>>
>> PS: Comments seems redundant to me
>>
>> 1660     // find out whether we are running on 64 bit processor or not.
>>
>> -Dmitry
>>
>> On 2013-08-09 03:59, Coleen Phillimore wrote:
>>> Mikael,
>>>
>>> I think this looks great.  It's a lot cleaner (more red than blue
>>> changes).
>>>
>>> thanks for humoring me,
>>> Coleen
>>>
>>> On 08/08/2013 06:25 PM, Mikael Vidstedt wrote:
>>>> Coleen,
>>>>
>>>> After having tried numerous different versions I ended up with this:
>>>>
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452.3/webrev
>>>>
>>>> Summary of the changes:
>>>>
>>>> * The GetNativeSystemInfo call has been moved up before the switch,
>>>> but is only called if the os version is recent enough, and  we
>>>> actually care about the si.wProcessorArchitecture field.
>>>>
>>>> * The true/else branches in the if-diamond have been switch to avoid
>>>> the negation of the condition.
>>>>
>>>> * While at it I added support for recognizing "Windows Server 2008 R2"
>>>> (6.1 non-workstation) which we apparently haven't recognized earlier,
>>>> but which is something the JDK code recognizes [1].
>>>>
>>>> * The " , 64 bit" has been move out below the switch, but is only
>>>> relevant/tested for on recent enough Windows versions, just like the
>>>> old code did.
>>>>
>>>> Feedback much appreciated! I'm also investigating if it would be
>>>> possible to unify/share the code with the java_props_md.c logic [1] to
>>>> avoid the duplication, but for now this may have to do. In addition to
>>>> that the code can be cleaned up further if we only support VS2010+,
>>>> which I believe is de facto since JDK 7 anyway; I will investigate
>>>> that as a separate improvement.
>>>>
>>>> Thanks,
>>>> Mikael
>>>>
>>>> [1]
>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/e057cddf0d6c/src/windows/native/java/lang/java_props_md.c
>>>>
>>>> (line 451).
>>>>
>>>> On 2013-08-07 10:56, Coleen Phillimore wrote:
>>>>> Mikael,
>>>>>
>>>>> I do like your new version better but because you changed so much, it
>>>>> should be verified on all versions of windows.   Which you might not
>>>>> want to do.   My suggestion to make this code nicer (fix case stmt
>>>>> and outline common code) was really simple and I think can be
>>>>> verified by code inspection, which might be less work and easier to
>>>>> review.
>>>>>
>>>>> Coleen
>>>>>
>>>>> On 8/7/2013 12:28 PM, Mikael Vidstedt wrote:
>>>>>> Coleen,
>>>>>>
>>>>>> Funny you should mention that, and since I fully agree with you I
>>>>>> actually did prepare another version of the patch which is heavily
>>>>>> inspired by the java_props_md.c implementation:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/winvercleanup2/webrev/
>>>>>>
>>>>>> I personally like this version better, but the one thing that held
>>>>>> me back was the fact that I will basically want to dig up machines
>>>>>> with all the different (supported) Windows versions and verify that
>>>>>> the code is still correct in all cases. If you think this is the way
>>>>>> to go I more than willing to will do so. Let me know what you think
>>>>>> about the new version of the patch!
>>>>>>
>>>>>> There's no real urgency here - I'd rather do it correct once than...
>>>>>>
>>>>>> Cheers,
>>>>>> Mikael
>>>>>>
>>>>>>
>>>>>> On 2013-08-07 06:39, Coleen Phillimore wrote:
>>>>>>> It looks like the code under the case for all these releases,
>>>>>>> should be different case statements for each, rather than these
>>>>>>> cascading 'if' statements.  And make 1668-1673 a new function
>>>>>>> returning si.   So if we have a new release, in general it will
>>>>>>> work because the default will print out something.   But a better
>>>>>>> default would be lines 1712-1717 which are dead code now.
>>>>>>>
>>>>>>> Sorry, I know it's simple and urgent but this seems to be getting
>>>>>>> increasingly ugly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>> On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>>>>>>>> Please review the following change:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>>>>>>>>
>>>>>>>> The patch adds support to os_windows.cpp for recognizing the
>>>>>>>> upcoming Windows versions: Windows 8.1 and Windows Server 2012 R2.
>>>>>>>>
>>>>>>>> The changed is based on the corresponding code on the JDK
>>>>>>>> side[1][2][3].
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mikael
>>>>>>>>
>>>>>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
>>>>>>>> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
>>>>>>>> [3]
>>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>
> 


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

From mikael.vidstedt at oracle.com  Fri Aug  9 09:47:24 2013
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Fri, 09 Aug 2013 09:47:24 -0700
Subject: RFR (S): 8022452: Hotspot needs to know about Windows 8.1 and
	Windows Server 2012 R2
In-Reply-To: <520519BE.9020805@oracle.com>
References: <5201886C.1030206@oracle.com> <52024E1A.4000908@oracle.com>
	<520275B8.5010101@oracle.com> <52028A69.8010207@oracle.com>
	<52041AC1.4000803@oracle.com> <520430F3.4040306@oracle.com>
	<5204CF5E.30705@oracle.com> <5205164F.4040607@oracle.com>
	<520519BE.9020805@oracle.com>
Message-ID: <52051D1C.9040508@oracle.com>


Dmitry/Coleen/everybody else - thanks for the feedback!

Cheers,
Mikael

On 2013-08-09 09:33, Dmitry Samersoff wrote:
> Mikael,
>
> Fill free to continue.
>
> Changes looks OK for me.
>
> -Dmitry
>
> On 2013-08-09 20:18, Mikael Vidstedt wrote:
>> The Oracle JDK does not support the older Windows versions in JDK 7.
>> However, in an attempt to keep this change small I will keep those
>> checks in there and queue up a future cleanup task.
>>
>> Unless the comment is annoying you all too much I'll keep it in there too.
>>
>> Cheers,
>> Mikael
>>
>> On 2013-08-09 04:15, Dmitry Samersoff wrote:
>>> Mikael,
>>>
>>> Does we still support Win 95/98/Me ?
>>>
>>> PS: Comments seems redundant to me
>>>
>>> 1660     // find out whether we are running on 64 bit processor or not.
>>>
>>> -Dmitry
>>>
>>> On 2013-08-09 03:59, Coleen Phillimore wrote:
>>>> Mikael,
>>>>
>>>> I think this looks great.  It's a lot cleaner (more red than blue
>>>> changes).
>>>>
>>>> thanks for humoring me,
>>>> Coleen
>>>>
>>>> On 08/08/2013 06:25 PM, Mikael Vidstedt wrote:
>>>>> Coleen,
>>>>>
>>>>> After having tried numerous different versions I ended up with this:
>>>>>
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452.3/webrev
>>>>>
>>>>> Summary of the changes:
>>>>>
>>>>> * The GetNativeSystemInfo call has been moved up before the switch,
>>>>> but is only called if the os version is recent enough, and  we
>>>>> actually care about the si.wProcessorArchitecture field.
>>>>>
>>>>> * The true/else branches in the if-diamond have been switch to avoid
>>>>> the negation of the condition.
>>>>>
>>>>> * While at it I added support for recognizing "Windows Server 2008 R2"
>>>>> (6.1 non-workstation) which we apparently haven't recognized earlier,
>>>>> but which is something the JDK code recognizes [1].
>>>>>
>>>>> * The " , 64 bit" has been move out below the switch, but is only
>>>>> relevant/tested for on recent enough Windows versions, just like the
>>>>> old code did.
>>>>>
>>>>> Feedback much appreciated! I'm also investigating if it would be
>>>>> possible to unify/share the code with the java_props_md.c logic [1] to
>>>>> avoid the duplication, but for now this may have to do. In addition to
>>>>> that the code can be cleaned up further if we only support VS2010+,
>>>>> which I believe is de facto since JDK 7 anyway; I will investigate
>>>>> that as a separate improvement.
>>>>>
>>>>> Thanks,
>>>>> Mikael
>>>>>
>>>>> [1]
>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/e057cddf0d6c/src/windows/native/java/lang/java_props_md.c
>>>>>
>>>>> (line 451).
>>>>>
>>>>> On 2013-08-07 10:56, Coleen Phillimore wrote:
>>>>>> Mikael,
>>>>>>
>>>>>> I do like your new version better but because you changed so much, it
>>>>>> should be verified on all versions of windows.   Which you might not
>>>>>> want to do.   My suggestion to make this code nicer (fix case stmt
>>>>>> and outline common code) was really simple and I think can be
>>>>>> verified by code inspection, which might be less work and easier to
>>>>>> review.
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>> On 8/7/2013 12:28 PM, Mikael Vidstedt wrote:
>>>>>>> Coleen,
>>>>>>>
>>>>>>> Funny you should mention that, and since I fully agree with you I
>>>>>>> actually did prepare another version of the patch which is heavily
>>>>>>> inspired by the java_props_md.c implementation:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/winvercleanup2/webrev/
>>>>>>>
>>>>>>> I personally like this version better, but the one thing that held
>>>>>>> me back was the fact that I will basically want to dig up machines
>>>>>>> with all the different (supported) Windows versions and verify that
>>>>>>> the code is still correct in all cases. If you think this is the way
>>>>>>> to go I more than willing to will do so. Let me know what you think
>>>>>>> about the new version of the patch!
>>>>>>>
>>>>>>> There's no real urgency here - I'd rather do it correct once than...
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mikael
>>>>>>>
>>>>>>>
>>>>>>> On 2013-08-07 06:39, Coleen Phillimore wrote:
>>>>>>>> It looks like the code under the case for all these releases,
>>>>>>>> should be different case statements for each, rather than these
>>>>>>>> cascading 'if' statements.  And make 1668-1673 a new function
>>>>>>>> returning si.   So if we have a new release, in general it will
>>>>>>>> work because the default will print out something.   But a better
>>>>>>>> default would be lines 1712-1717 which are dead code now.
>>>>>>>>
>>>>>>>> Sorry, I know it's simple and urgent but this seems to be getting
>>>>>>>> increasingly ugly.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>> On 8/6/2013 7:36 PM, Mikael Vidstedt wrote:
>>>>>>>>> Please review the following change:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8022452/webrev
>>>>>>>>>
>>>>>>>>> The patch adds support to os_windows.cpp for recognizing the
>>>>>>>>> upcoming Windows versions: Windows 8.1 and Windows Server 2012 R2.
>>>>>>>>>
>>>>>>>>> The changed is based on the corresponding code on the JDK
>>>>>>>>> side[1][2][3].
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mikael
>>>>>>>>>
>>>>>>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020191
>>>>>>>>> [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f
>>>>>>>>> [3]
>>>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019463.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>


From mikhailo.seledtsov at oracle.com  Fri Aug  9 09:49:14 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Fri, 09 Aug 2013 12:49:14 -0400
Subject: RFR 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
In-Reply-To: <520427F9.8030805@oracle.com>
References: <52016BBB.3040907@oracle.com> <520423B6.3050009@oracle.com>
	<520427F9.8030805@oracle.com>
Message-ID: <52051D8A.20009@oracle.com>

Hi Coleen,

  I have reviewed only the test portion of your change-set.
It was a good learning exercise for me on class transformation.
I have several comments:

1. Agent.java: redefine()
     With your change, the block of code

	Agent transformer = new Agent();
	instrumentation.addTransformer(transformer, true);

will be called 3 times, thus adding the transformer 3 times.
Was it intended? If not, you could move this code to premain()

2. WalkThroughInvoke.java: stackWalk()
    If the AccessControlException() is always expected, and making sure it occurs is one of the test checks, I recommend throwing an exception
    right after sm.checkMemberAccess(b, Member.DECLARED);

    Such as:

   try {
   28       Class b = Object.class;
   29       SecurityManager sm = new SecurityManager();
   30       // walks the stack before it gets this exception.
   31       // testing the stack walk with Method.invoke in the stack
   32       sm.checkMemberAccess(b, Member.DECLARED);
*   Misha>>  throw new Exception("Test failed, the expected AccessControlException did not occur");*
   33     } catch (java.security.AccessControlException e) {
   34       System.out.println("This exception is expected");
   35     }


3. Style comment:
    The style for Java code is to use 4 spaces for tabulation/indent
(please see the attached discussion with David Holmes).
    

Misha


On 8/8/2013 7:21 PM, Coleen Phillimore wrote:
>
> Thanks, Serguei!
> Coleen
>
> On 08/08/2013 07:03 PM, serguei.spitsyn at oracle.com wrote:
>> Coleen,
>>
>> The fix looks good, I do not see any issues.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 8/6/13 2:33 PM, Coleen Phillimore wrote:
>>> Summary: ActiveMethodOopsCache was used to keep track of old 
>>> versions of some methods that are cached in Universe but is buggy 
>>> with permgen removal and not needed anymore
>>>
>>> There was a crash in this function that I couldn't reproduce. It was 
>>> likely that the crash was for something else, but this is a lurking 
>>> bug.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8009728/
>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009728
>>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8009728
>>>
>>> Tested with vm.quick.testlist which includes redefine classes tests 
>>> and jck lang and vm tests.
>>>
>>> Thanks,
>>> Coleen
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/0f5a251a/attachment-0001.html 
-------------- next part --------------
An embedded message was scrubbed...
From: David Holmes <david.holmes at oracle.com>
Subject: Re: RFR (S): 6726963: multi_allocate() call does not CHECK_NULL and
	causes crash in fastdebug bits
Date: Mon, 03 Jun 2013 22:28:05 +1000
Size: 3628
Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/0f5a251a/Code_Tabulation_Style__Email01-0001.eml 

From mikhailo.seledtsov at oracle.com  Fri Aug  9 10:36:24 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Fri, 09 Aug 2013 13:36:24 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
Message-ID: <52052898.4000702@oracle.com>

Hi Harold,

  I have reviewed only the test portion of the change. It looks good, I 
have couple of comments:
- style comment: we should try to use 4 spaces for indent/tabulation in 
Java code
- this comment may be coming too late in the checking process: what do 
you think about keeping all the CDS tests in the same place, under 
test/runtime/SharedArchiveFile ?
   If you agree, but it is too late to make this change, I could make 
this change later as a separate trivial check-in.

Misha

On 8/9/2013 10:57 AM, Harold Seigel wrote:
> Hi,
>
> Please review this latest version of the bug fix for 8003424: 
> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.3/>
>
>
> This new version includes the following changes:
>
> 1. macroAssembler_sparc.cpp
>
>    a. Merged two versions of reinit_heapbase() into one.
>
>    b. Improved decode_klass_not_null(src, dst) to not use G6 if shift 
> == 0.
>
>
> 2. macroAssembler_x86.cpp
>
>    a. Merged two versions of reinit_heapbase() into one.
>
>    b. Improved encode_klass_not_null(src, dst) to not use R12.
>
>    c. Replaced leaq with addq in decode_klass_not_null(src, dst).
>
>
> 3. Improved variable names in heap.cpp.
>
>
> 4. metaspace.cpp
>
>    a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more 
> understandable.
>
>    b. Moved set_narrow_klass_base_and_shift() near 
> can_use_cds_with_metaspace_addr().
>
>    c. Changed unneeded conditional in initialize_class_space() into an 
> assert.
>
>
> 5. arguments.cpp
>
>    a. Fixed problem with -Xshare:dump and disabled compression.
>
>    b. Moved UseCompressedKlassPointers code into new function: 
> set_use_compressed_klass_ptrs().
>
>    c. Fixed bug 8005933 that turned off CDS for -server even if 
> -Xshare:auto was explicitly specified.
>
>
> 6. Increased default value of ClassMetaspaceSize to 1*G in globals.hpp.
>
>
> 7. Fixed indentation issues in metaspace.cpp and other modules.
>
>
> Thanks, Harold
>
> ----- Original Message -----
> From: harold.seigel at oracle.com
> To: coleen.phillimore at oracle.com
> Cc: hotspot-runtime-dev at openjdk.java.net
> Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern
> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing 
> for CompressedOops
>
> The purpose of this assert is to verify that the two methods in the 
> 'if' clause closed the map file and disabled UseSharedSpaces if they 
> detected a problem when trying to use CDS.
>
>       if (mapinfo->initialize() && 
> MetaspaceShared::map_shared_spaces(mapinfo)) {
>         FileMapInfo::set_current_info(mapinfo);
>       } else {
>         assert(!mapinfo->is_open() && !UseSharedSpaces,
>                "archive file not closed or shared spaces not disabled.");
>       }
>
> ----- Original Message -----
> From: harold.seigel at oracle.com
> To: coleen.phillimore at oracle.com
> Cc: hotspot-runtime-dev at openjdk.java.net
> Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing 
> for CompressedOops
>
> This is a bug that Stefan Karlsson also discovered.  To fix it, I've 
> changed the code to this:
>
>   if (DumpSharedSpaces) {
>     if (RequireSharedSpaces) {
>       warning("cannot dump shared archive while using shared archive");
>     }
>     UseSharedSpaces = false;
> #ifdef _LP64
>     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>       vm_exit_during_initialization(
>         "Cannot dump shared archive when UseCompressedOops or 
> UseCompressedKlassPointers is off.", NULL);
>     }
>
> Harold
>
>
> ----- Original Message -----
> From: coleen.phillimore at oracle.com
> To: hotspot-runtime-dev at openjdk.java.net
> Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing 
> for CompressedOops
>
>
> Yes, there should be a check for that too.  Now I'll really let Harold
> answer.
>
> Thanks,
> Coleen
>
> On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
> > Coleen, Harold
> >
> > > The InstanceKlass has offsets to fields in the instance, and they
> > depend
> > > on both compressed oops and compressed klass pointers.   So both
> > have to
> > > be on for the offsets to be valid.
> >
> > So there is dependency on UseCompressedOops and
> > UseCompressedKlassPointers flags during dump.
> >
> > Then why the check is done only for UseSharedSpaces and not for
> > DumpSharedSpaces?:
> >
> >     if (DumpSharedSpaces) {
> >       if (RequireSharedSpaces) {
> >         warning("cannot dump shared archive while using shared 
> archive");
> >       }
> >       UseSharedSpaces = false;
> > + #ifdef _LP64
> > +   } else {
> > +     // UseCompressedOops and UseCompressedKlassPointers must be on
> > for UseSharedSpaces.
> > +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
> > +       no_shared_spaces();
> > +     }
> > + #endif
> >     }
> >
> > Thanks,
> > Vladimir
> >
> > On 8/8/13 3:34 PM, Coleen Phillimore wrote:
> >>
> >> Hi Vladimir,
> >>
> >> I have a couple of answers and I'll let Harold answer the rest.
> >>
> >> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
> >>> On 8/7/13 8:34 AM, harold seigel wrote:
> >>>> Hi Vladimir,
> >>>>
> >>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
> >>>>> Harold,
> >>>>>
> >>>>> Note, on SPARC set() could generate up to 8 instructions to load
> >>>>> 64-bit constant into register. So I am not sure that it will be
> >>>>> faster
> >>>>> than load.
> >>>> We thought it would be faster because it doesn't need to load 
> anything
> >>>> from memory.
> >>>
> >>> For good value (0x800000000) it should use only 2-3 instructions.
> >>> I think you can keep using set().
> >>>
> >>>>>
> >>>>> I can't find where in CDS you store information about compressed
> >>>>> klass
> >>>>> pointers and compressed oops parameters which were used during dump?
> >>>>> How you verify that correct parameters/flags are ussed when such CDS
> >>>>> is used later?
> >>>> No compressed klass pointers nor compressed oops get written to the
> >>>> archive.  So, the compressed klass pointers and compressed oops
> >>>> parameters do not need to be recorded in the archive.
> >>>
> >>> So you are saying that all klass pointers (references to klasses) in
> >>> metadata structures in metaspace are full.
> >>
> >> Yes, they are.  (methodOops weren't in the InstanceKlass::_methods 
> array
> >> with Permgen but they are uncompressed now).
> >>
> >>> And klass pointers are only compressed in java object headers (which
> >>> are not part of CDS). Right?
> >>
> >> The InstanceKlass has offsets to fields in the instance, and they 
> depend
> >> on both compressed oops and compressed klass pointers.   So both 
> have to
> >> be on for the offsets to be valid.
> >>
> >> But the base and compressed values are not stored anywhere in the CDS
> >> archive.
> >>
> >>> And you don't care about UseCompressedOops and
> >>> UseCompressedKlassPointers flags settings when you dump it into
> >>> archive. The only limit is:
> >>>
> >>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total
> >>>
> >>> Then I don't understand why you can't use/load CDS archive when coop
> >>> or compklass are off:
> >>>
> >>> > If coop is turned off then CDS cannot be used.  CDS will only be
> >>> > supported if both UseCompressedOops and UseCompressedKlassPointers
> >>> are
> >>> > TRUE.
> >>>
> >>> Also based on code in arguments.cpp it is allowed to specify
> >>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command 
> line:
> >>>
> >>> 1466     // Turn on UseCompressedKlassPointers too
> >>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
> >>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
> >>> 1469     }
> >>>
> >>> Did you tested such combination?
> >>
> >> I should let Harold answer this but I believe this is what his test
> >> does.  For CDS on 64 bit, both must be on.   We didn't want to create 4
> >> different archives.   And it wouldn't make too much sense since CDS for
> >> 64 bit is a footprint savings so why would you use it without
> >> compressing oops and class pointers?  It's not a startup savings on
> >> server because we turn off interpreter bytecode quickening.
> >>
> >> Coleen
> >>
> >>>
> >>>>>
> >>>>> set_narrow_klass_base_and_shift() and
> >>>>> can_use_cds_with_metaspace_addr() have the same code for
> >>>>> UseSharedSpaces. It would be nice to have only one copy. Call
> >>>>> can_use_cds_with_metaspace_addr() from
> >>>>> set_narrow_klass_base_and_shift() ?
> >>>> I could add new inlined methods that determine the higher_address and
> >>>> lower_base when UseSharedSpaces is true and have them called from
> >>>> set_narrow_klass_base_and_shift() and
> >>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
> >>>
> >>> I tried several approaches but your implementation is more clean. So I
> >>> agree to keep what you have now.
> >>>
> >>>
> >>> Also I found strange assert which should always fail (old code in
> >>> global_initialize() in metaspace.cpp):
> >>>
> >>> 2959     if (UseSharedSpaces) {
> >>> ...
> >>> 2969       } else {
> >>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
> >>> 2971                "archive file not closed or shared spaces not
> >>> disabled.");
> >>>
> >>> Thanks,
> >>> Vladimir
> >>>
> >>>>>
> >>>>> I see that you unconditionally set comp klass ptr base and shift for
> >>>>> DumpSharedSpaces. Should you do the check similar to
> >>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
> >>>>> don't even check UseCompressedKlassPointers.
> >>>> I don't think the checks are needed because the information 
> written to
> >>>> the archive is not affected by the size of the class metaspace.
> >>>>
> >>>> Also, I recently added code to arguments.cpp that will generate an
> >>>> error
> >>>> if UseCompressedOops or UseCompressedKlassPointers is turned off and
> >>>> DumpSharedSpaces is on.
> >>>>>
> >>>>> Why you have next limitation? What if coop can't be used because of
> >>>>> big heap?:
> >>>>>
> >>>>> +     // UseCompressedOops and UseCompressedKlassPointers must be on
> >>>>> for UseSharedSpaces.
> >>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
> >>>>> +       no_shared_spaces();
> >>>> If coop is turned off then CDS cannot be used.  CDS will only be
> >>>> supported if both UseCompressedOops and 
> UseCompressedKlassPointers are
> >>>> TRUE.
> >>>>>
> >>>>> Could you move UseCompressedKlassPointers code in arguments.cpp into
> >>>>> separate method similar to set_use_compressed_oops()?
> >>>> Done.
> >>>>>
> >>>>> About new tests.
> >>>>> The first test in CDSCompressedKPtrsError misses
> >>>>> -XX:+UseCompressedOops flag.
> >>>> Fixed.
> >>>>>
> >>>>> Could you also test cross flags combinations?:
> >>>>>
> >>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
> >>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
> >>>> Done.
> >>>>>
> >>>>> It would be nice to have test to check ClassMetaspaceSize value
> >>>>> range.
> >>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither 
> maxint
> >>>>> or maxuint.
> >>>> A member of our runtime SQE group is writing additional tests. I'll
> >>>> ask
> >>>> him to write a ClassMetaspaceSize range test.
> >>>>
> >>>> We chose 3Gb because we thought it was a sufficiently large size.
> >>>>>
> >>>>>
> >>>>> About code style, indention. We align next line to corresponding 
> part
> >>>>> of previous line if we need to split a line. And sometimes it is
> >>>>> better to keep one long line. I understand some of them were before
> >>>>> your changes but, please, clean up at lest ones you touched.
> >>>> Done.
> >>>>>
> >>>>> Cases in metaspace.cpp:
> >>>>>
> >>>>> 2263   assert(raw_word_size >= min_size,
> >>>>> 2264     err_msg("Should not deallocate dark matter " 
> SIZE_FORMAT "<"
> >>>>> SIZE_FORMAT, word_size, min_size));
> >>>>>
> >>>>>
> >>>>> 2485   if (Metaspace::using_class_space() &&
> >>>>> 2486     (Metaspace::class_space_list() != NULL)) {
> >>>>>
> >>>>>
> >>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
> >>>>> 2575 (Metaspace::using_class_space() ?
> >>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
> >>>>> 2577 Metaspace::space_list()->virtual_space_total();
> >>>>>
> >>>>>
> >>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
> >>>>> SIZE_FORMAT ", "
> >>>>> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT
> >>>>> ", "
> >>>>> 2696                            SIZE_FORMAT " medium(s) " 
> SIZE_FORMAT
> >>>>> ", "
> >>>>> 2697                            "large count " SIZE_FORMAT,
> >>>>> 2698              cls_specialized_count, cls_specialized_waste,
> >>>>> 2699              cls_small_count, cls_small_waste,
> >>>>> 2700              cls_medium_count, cls_medium_waste,
> >>>>> cls_humongous_count);
> >>>>>
> >>>>>
> >>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G >
> >>>>> addr) &&
> >>>>> 2873 can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
> >>>>>
> >>>>>
> >>>>> 2889 vm_exit_during_initialization(err_msg(
> >>>>> 2890           "Could not allocate metaspace: %d bytes",
> >>>>> 2891           class_metaspace_size()));
> >>>>>
> >>>>>
> >>>>> 3107     return using_class_space() ?
> >>>>> 3108 class_vsm()->sum_used_in_chunks_in_use() : 0;
> >>>>>
> >>>>>
> >>>>> 3157     if (is_class && using_class_space()) {
> >>>>> 3158        class_vsm()->deallocate(ptr, word_size);
> >>>>>
> >>>>>
> >>>>> 3305   return space_list()->contains(ptr) ||
> >>>>> 3306     (using_class_space() && class_space_list()->contains(ptr));
> >>>>>
> >>>>> metaspace.hpp:
> >>>>>
> >>>>>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
> >>>>>  271       (Metaspace::using_class_space() ?
> >>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
> >>>>>
> >>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
> >>>>>  286       (Metaspace::using_class_space() ?
> >>>>>  287 _allocated_used_words[Metaspace::ClassType] : 0);
> >>>>>
> >>>>> universe.cpp:
> >>>>>
> >>>>>  849 assert((intptr_t)Universe::narrow_oop_base() <=
> >>>>> (intptr_t)(Universe::heap()->base() -
> >>>>>  850     os::vm_page_size()) ||
> >>>>>  851            Universe::narrow_oop_base() == NULL, "invalid
> >>>>> value");
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Vladimir
> >>>>>
> >>>>> On 8/2/13 1:31 PM, harold seigel wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Please review this updated webrev for bug 8003424:
> >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
> >>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
> >>>>>>
> >>>>>> The updated webrev has a lot of changes from the previous webrev,
> >>>>>> including the following:
> >>>>>>
> >>>>>>     1. Class metaspace information is now output when
> >>>>>>     -XX:+PrintCompressedOopsMode is specified.
> >>>>>>
> >>>>>>     2. decode_klass_not_null(Register dst, Register src) no longer
> >>>>>>     clobbers R12.
> >>>>>>
> >>>>>>     3. Method using_class_vsm() was renamed to using_class_space().
> >>>>>>
> >>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
> >>>>>> appropriate.
> >>>>>>
> >>>>>>     5. The Metaspace:: qualifier was removed, where it was
> >>>>>> unnecessary.
> >>>>>>
> >>>>>>     6. Metaspace::initialize_class_space() was made private.
> >>>>>>
> >>>>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
> >>>>>> updated.
> >>>>>>
> >>>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005,
> >>>>>> and
> >>>>>> specjbb2013.  The results showed no significant performance
> >>>>>> difference
> >>>>>> in terms of scores and gc behavior.
> >>>>>>
> >>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
> >>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
> >>>>>>
> >>>>>> Please let me know what additional tests should be run.
> >>>>>>
> >>>>>> Thanks!
> >>>>>> Harold
> >>>>>>
> >>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
> >>>>>>> Hi Harold,
> >>>>>>>
> >>>>>>> > Usually the narrow_klass_base will be 32G and the
> >>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which
> >>>>>>> means
> >>>>>>> that
> >>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
> >>>>>>> unless
> >>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that
> >>>>>>> make
> >>>>>>> sense?
> >>>>>>>
> >>>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000
> >>>>>>> and I
> >>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
> >>>>>>> (assuming or
> >>>>>>> with check that class metaspace size < 32Gb).
> >>>>>>>
> >>>>>>> > Is there one prefix byte per instruction, or just for certain
> >>>>>>> instructions?
> >>>>>>>
> >>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
> >>>>>>> prefix is
> >>>>>>> necessary only if an instruction references one of the extended
> >>>>>>> registers or uses a 64-bit operand."
> >>>>>>>
> >>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and
> >>>>>>> =32
> >>>>>>> and big java heap. Recently we got several bugs which indicated
> >>>>>>> that
> >>>>>>> we did not separate cleanly oops and klass pointers en/decoding.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Vladimir
> >>>>>>>
> >>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
> >>>>>>>> Hi Vladimir,
> >>>>>>>>
> >>>>>>>> Thank you for the review!  Please see inline comments.
> >>>>>>>>
> >>>>>>>> Thanks, Harold
> >>>>>>>>
> >>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
> >>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
> >>>>>>>>>> Nice clean up, Harold
> >>>>>>>>>>
> >>>>>>>>>> Could you add the size of class metaspace in output with
> >>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
> >>>>>>>>>> remember an
> >>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
> >>>>>>>> Will be done in next webrev.
> >>>>>>>>>>
> >>>>>>>>>> Also it would be nice to print these info line (and compressed
> >>>>>>>>>> oops
> >>>>>>>>>> info
> >>>>>>>>>> line) in hs_err files.
> >>>>>>>> I filed an enhancement bug for this: 8021264
> >>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
> >>>>>>>>>>
> >>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
> >>>>>>>>>> x86_64.ad.
> >>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use
> >>>>>>>>>> arithmetic
> >>>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also
> >>>>>>>>>> note
> >>>>>>>>>> that code in .ad file does not check the encoding mode for
> >>>>>>>>>> narrow
> >>>>>>>>>> klass/oop so it should be conservative and assume that
> >>>>>>>>>> arithmetic
> >>>>>>>>>> instructions are used.
> >>>>>>>> OK. Thanks.
> >>>>>>>>>>
> >>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base 
> below
> >>>>>>>>>> 4Gb so
> >>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
> >>>>>>>>>> encoding/decoding without destroying R12.
> >>>>>>>>>
> >>>>>>>>> Correction. You can do it only if base < 2Gb max positive int
> >>>>>>>>> (sign
> >>>>>>>>> bit is extended so you will get wrong result with address > 
> 2gb).
> >>>>>>>> But the base will normally be 32Gb.  So this case won't happen
> >>>>>>>> very
> >>>>>>>> often.
> >>>>>>>>>
> >>>>>>>>> You definitely should not use R12 in
> >>>>>>>>> decode_klass_not_null(Register
> >>>>>>>>> dst, Register src) method where you have free 'dst' register.
> >>>>>>>> Will be fixed in next webrev.
> >>>>>>>>>
> >>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). 
> Actually it
> >>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be
> >>>>>>>>> 64Gb.
> >>>>>>>>> The idea was to avoid using R12 by using shifted base:
> >>>>>>>>>
> >>>>>>>>> decode:
> >>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
> >>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
> >>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
> >>>>>>>>>   }
> >>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
> >>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
> >>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <=
> >>>>>>>>> maxint
> >>>>>>>>> (max positive int).
> >>>>>>>> Usually the narrow_klass_base will be 32G and the
> >>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which 
> means
> >>>>>>>> that
> >>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
> >>>>>>>> unless
> >>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that
> >>>>>>>> make
> >>>>>>>> sense?
> >>>>>>>>>
> >>>>>>>>> And you have general memory reservation problem. At least on
> >>>>>>>>> Solaris,
> >>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
> >>>>>>>>> between
> >>>>>>>>> different requested memory regions. That is why in jdk7 we first
> >>>>>>>>> reserve one huge space and then cut it on java heap, perm 
> gen and
> >>>>>>>>> protection page below heap to catch implicit NULL exceptions 
> with
> >>>>>>>>> compressed oops.
> >>>>>>>>>
> >>>>>>>>> So, please, verify that you are getting 'cds_address + 
> cds_total'
> >>>>>>>>> address or CompressedKlassPointersBase without CDS and with
> >>>>>>>>> compressed
> >>>>>>>>> oops and with Xmx20Gb.
> >>>>>>>> I verifed that we get either cds_address+cds_total as the
> >>>>>>>> address, or
> >>>>>>>> CompressedKlassPointersBase as the address without CDS on Linux,
> >>>>>>>> Windows
> >>>>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap
> >>>>>>>> sizes and
> >>>>>>>> -Xmx32G.
> >>>>>>>>
> >>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the
> >>>>>>>> desired
> >>>>>>>> CDS address for class metaspace regardless of heap size.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
> >>>>>>>>>> unfortunately we
> >>>>>>>>>> can't do other way. I assume you use max size because
> >>>>>>>>>> depending on
> >>>>>>>>>> registers used in instructions you will or will not get prefix
> >>>>>>>>>> byte
> >>>>>>>>>> (r8-r15).
> >>>>>>>> Is there one prefix byte per instruction, or just for certain
> >>>>>>>> instructions?
> >>>>>>>>>>
> >>>>>>>>>> I will look on changes in more details may be late.
> >>>>>>>>>
> >>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use
> >>>>>>>>> abbreviations
> >>>>>>>>> which are not obvious.
> >>>>>>>> I changed using_class_vsm() to using_class_space().
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Vladimir
> >>>>>>>>>>
> >>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> Please review this fix for bug 8003424.
> >>>>>>>>>>>
> >>>>>>>>>>> Open webrev at 
> http://cr.openjdk.java.net/~hseigel/bug_8003424/
> >>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
> >>>>>>>>>>> Open bug links at:
> >>>>>>>>>>>
> >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
> >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
> >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
> >>>>>>>>>>>
> >>>>>>>>>>> JBS Bug links at
> >>>>>>>>>>>
> >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
> >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
> >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> This fix provides support for using compressed klass pointers
> >>>>>>>>>>> with
> >>>>>>>>>>> CDS.
> >>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
> >>>>>>>>>>> platforms
> >>>>>>>>>>> when
> >>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the
> >>>>>>>>>>> class
> >>>>>>>>>>> metaspace as part of the Java Heap allocation and locating
> >>>>>>>>>>> it at
> >>>>>>>>>>> the
> >>>>>>>>>>> base of that allocation, the metaspace will now be allocated
> >>>>>>>>>>> separately,
> >>>>>>>>>>> above the Java heap.  This will enable future expansion of the
> >>>>>>>>>>> metaspace
> >>>>>>>>>>> because it won't be backed up against the Java heap. If CDS is
> >>>>>>>>>>> being
> >>>>>>>>>>> used, then the CDS region will be allocated between the Java
> >>>>>>>>>>> heap and
> >>>>>>>>>>> the metaspace.
> >>>>>>>>>>>
> >>>>>>>>>>> The new class metaspace allocation code tries to allocate
> >>>>>>>>>>> memory at
> >>>>>>>>>>> 32G,
> >>>>>>>>>>> or above the CDS region, if it is present. Because of this,
> >>>>>>>>>>> encoding
> >>>>>>>>>>> and decoding of compressed klass pointers will always
> >>>>>>>>>>> require use
> >>>>>>>>>>> of a
> >>>>>>>>>>> base register.  So, encoding and decoding of compressed klass
> >>>>>>>>>>> pointers
> >>>>>>>>>>> will differ from compressed oops.
> >>>>>>>>>>>
> >>>>>>>>>>> There are no class metaspace allocation changes if
> >>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
> >>>>>>>>>>> 32-bit
> >>>>>>>>>>> platform.
> >>>>>>>>>>>
> >>>>>>>>>>> The code changes also include some cleanup and will fix bugs
> >>>>>>>>>>> 8016729,
> >>>>>>>>>>> 8011610, and 8003424.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Many of the modules in this webrev contain a lot of changes.
> >>>>>>>>>>> Modules
> >>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
> >>>>>>>>>>> changed to
> >>>>>>>>>>> support the new encoding and decoding of compressed klass
> >>>>>>>>>>> pointers.
> >>>>>>>>>>>
> >>>>>>>>>>> Module metaspace.cpp was changed significantly to support
> >>>>>>>>>>> the new
> >>>>>>>>>>> allocation for metaspace and the CDS region and to determine
> >>>>>>>>>>> compressed
> >>>>>>>>>>> klass pointer encoding base and shifting values.
> >>>>>>>>>>>
> >>>>>>>>>>> Most of the changes to module universe.cpp were to remove code
> >>>>>>>>>>> related
> >>>>>>>>>>> to allocating metaspace and remove code that considered
> >>>>>>>>>>> compressed
> >>>>>>>>>>> klass
> >>>>>>>>>>> pointers when determining the compressed oops compression
> >>>>>>>>>>> mechanism.
> >>>>>>>>>>>
> >>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as
> >>>>>>>>>>> part
> >>>>>>>>>>> of a
> >>>>>>>>>>> cleanup requested by Coleen.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
> >>>>>>>>>>> tests,
> >>>>>>>>>>> JPRT,
> >>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and
> >>>>>>>>>>> vm.mlvm.testlist
> >>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and
> >>>>>>>>>>> -Xshare:off
> >>>>>>>>>>> (with
> >>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit
> >>>>>>>>>>> Linux and
> >>>>>>>>>>> 64-Bit
> >>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK 
> tests
> >>>>>>>>>>> were
> >>>>>>>>>>> run on Solaris x86.
> >>>>>>>>>>>
> >>>>>>>>>>> The performance impact of these changes is TBD.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks, Harold
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/83d9d4fa/attachment-0001.html 

From coleen.phillimore at oracle.com  Fri Aug  9 13:44:51 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 09 Aug 2013 16:44:51 -0400
Subject: RFR 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
In-Reply-To: <52051D8A.20009@oracle.com>
References: <52016BBB.3040907@oracle.com> <520423B6.3050009@oracle.com>
	<520427F9.8030805@oracle.com> <52051D8A.20009@oracle.com>
Message-ID: <520554C3.40208@oracle.com>


Hi Misha,

Thank you for reviewing the test.

On 8/9/2013 12:49 PM, Mikhailo Seledtsov wrote:
> Hi Coleen,
>
>  I have reviewed only the test portion of your change-set.
> It was a good learning exercise for me on class transformation.
> I have several comments:
>
> 1. Agent.java: redefine()
>     With your change, the block of code
>
> 	Agent transformer = new Agent();
> 	instrumentation.addTransformer(transformer, true);
>
> will be called 3 times, thus adding the transformer 3 times.
> Was it intended? If not, you could move this code to premain()

It wasn't intended.   I meant to move that to premain and have moved it 
and the test still passes.
>
> 2. WalkThroughInvoke.java: stackWalk()
>     If the AccessControlException() is always expected, and making sure it occurs is one of the test checks, I recommend throwing an exception
>     right after sm.checkMemberAccess(b, Member.DECLARED);
>
>     Such as:
>
>    try {
>    28       Class b = Object.class;
>    29       SecurityManager sm = new SecurityManager();
>    30       // walks the stack before it gets this exception.
>    31       // testing the stack walk with Method.invoke in the stack
>    32       sm.checkMemberAccess(b, Member.DECLARED);
> *   Misha>>  throw new Exception("Test failed, the expected AccessControlException did not occur");*
>    33     } catch (java.security.AccessControlException e) {
>    34       System.out.println("This exception is expected");
>    35     }
>

I don't think I want to do this change because if we change whether the 
checkMemberAccess() throws an exception, which seems unlikely, the test 
will start failing.   And so someone will have to fix the test for 
something that it's not trying to test.
> 3. Style comment:
>     The style for Java code is to use 4 spaces for tabulation/indent
> (please see the attached discussion with David Holmes).
>     

I changed the files to have 4 space indentation.

Thanks!
Coleen
>
> Misha
>
>
> On 8/8/2013 7:21 PM, Coleen Phillimore wrote:
>>
>> Thanks, Serguei!
>> Coleen
>>
>> On 08/08/2013 07:03 PM, serguei.spitsyn at oracle.com wrote:
>>> Coleen,
>>>
>>> The fix looks good, I do not see any issues.
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 8/6/13 2:33 PM, Coleen Phillimore wrote:
>>>> Summary: ActiveMethodOopsCache was used to keep track of old 
>>>> versions of some methods that are cached in Universe but is buggy 
>>>> with permgen removal and not needed anymore
>>>>
>>>> There was a crash in this function that I couldn't reproduce. It 
>>>> was likely that the crash was for something else, but this is a 
>>>> lurking bug.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8009728/
>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009728
>>>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8009728
>>>>
>>>> Tested with vm.quick.testlist which includes redefine classes tests 
>>>> and jck lang and vm tests.
>>>>
>>>> Thanks,
>>>> Coleen
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/559e3641/attachment.html 

From jiangli.zhou at oracle.com  Fri Aug  9 14:22:55 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 09 Aug 2013 14:22:55 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <51F978B6.3050209@oracle.com>
References: <51F978B6.3050209@oracle.com>
Message-ID: <52055DAF.90707@oracle.com>

Hi,

Could anyone help me review this?

Thanks,
Jiangli

On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
> Hi,
>
> Please review following change for JDK-8021948 
> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>
> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>
> Both InstanceKlass::_source_file_name and 
> InstanceKlass::_generic_signature were pointers to Symbol. They are 
> now indexes to constant pool entries. Both fields are now u2 type, and 
> co-located with other non-pointer type fields for more efficient 
> alignment on 64-bit machine. On 32-bit machine, the change saves 
> 4bytes for each class.
>
> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
> nsk.stress.testlist and nsk.jvmti.testlist.
>
> Thanks,
> Jiangli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/07a760a5/attachment.html 

From calvin.cheung at oracle.com  Fri Aug  9 15:11:28 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 09 Aug 2013 15:11:28 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <520425BD.6090605@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
Message-ID: <52056910.8010005@oracle.com>

I've updated the webrev with 2 changes:
1) added the TRAPS as the last parameter to the 
create_class_path_entry() method;
2) added a jtreg test case.

http://cr.openjdk.java.net/~ccheung/8020675/webrev/

Please take a look again.

One more response in-lined below...

On 8/8/2013 4:11 PM, Ioi Lam wrote:
> |I found one version of JDK7 that does not crash:||
> ||
> sc11136754 ~$ 
> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
> -showversion -cp . -Xbootclasspath/a:foo.jar test2
> Error occurred during initialization of VM
> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
> |

|I noticed that it started breaking in 7u40 b01; it was still working 
with 7u25.
It may have something to do with when the set_init_completed() is called:
ExceptionMark::~ExceptionMark() {
   if (_thread->has_pending_exception()) {
     Handle exception(_thread, _thread->pending_exception());
     _thread->clear_pending_exception(); // Needed to avoid infinite 
recursion
     if (is_init_completed()) {
       exception->print();
       fatal("ExceptionMark destructor expects no pending exceptions");
     } else {
       vm_exit_during_initialization(exception);
     }
   }
}

Before 7u40, I think the code path got to the "else" branch of 
~ExceptionMark() and we just printed an error and exit.

set_init_completed() is only called from Threads::create_vm() and that 
method didn't change much between 7u25 and 7u40 except for some NMT 
initialization - MemTracker::bootstrap_single_thread(), 
MemTracker::start(), etc. But I thought NMT isn't enabled by default?

Debugging with hs25, the set_init_completed() always happened before 
create_class_path_entry() and both calls were done within the same 
thread - "vm startup".

thanks,
Calvin


|
> |||
> ||
> ||- Ioi
> |
> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>> |I found an official version that's closest to the Redhat version 
>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still 
>> crashes.||
>> ||
>> ||sc11136754 ~$ 
>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion 
>> -cp . -Xbootclasspath/a:foo.jar test2||
>> ||java version "1.6.0_25"||
>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>> ||
>> ||java.lang.ClassNotFoundException ||
>> || - klass: 'java/lang/ClassNotFoundException'||
>> ||#||
>> ||# A fatal error has been detected by the Java Runtime Environment:||
>> ||#||
>> ||#  Internal Error (exceptions.cpp:397), pid=29955, 
>> tid=140608485558016||
>> ||#  fatal error: ExceptionMark destructor expects no pending 
>> exceptions||
>> ||#||
>> ||# JRE version: 6.0_25-b06||
>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode 
>> linux-amd64 compressed oops)||
>> ||# An error report file with more information is saved as:||
>> ||# /home/iklam/hs_err_pid29955.log||
>> ||#||
>> ||# If you would like to submit a bug report, please visit:||
>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>> ||#||
>> ||Aborted (core dumped)||
>> |
>> - Ioi
>>
>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which 
>>>> apparently
>>>> works differently
>>>> (better?) than the official JDK6 build. Maybe Redhat fixed this in 
>>>> their
>>>> own repo??||
>>>
>>> Their hotspot version is much later - hs20 vs hs17
>>>
>>> David
>>> -----
>>>
>>>> ||
>>>> |
>>>> |==OEL6================================================
>>>> ||
>>>> ||sc11136754 ~$ uname -a||
>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>> ||sc11136754 ~$ type java||
>>>> ||java is hashed (/usr/bin/java)||
>>>> ||sc11136754 ~$ java -version||
>>>> ||java version "1.6.0_22"||
>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar 
>>>> test2||
>>>> ||Error occurred during initialization of VM||
>>>> ||java/lang/ClassNotFoundException: error in opening JAR file 
>>>> foo.jar||
>>>> ||
>>>> ==OFFICIAL============================================
>>>> ||
>>>> sc11136754 ~$ /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>> java version "1.6.0_22"
>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>
>>>> #
>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>> #
>>>> #  Internal Error (exceptions.cpp:367), pid=25167, tid=140510319580928
>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>> #
>>>> # JRE version: 6.0_22-b04
>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>> linux-amd64 )
>>>> # An error report file with more information is saved as:
>>>> # /home/iklam/hs_err_pid25167.log
>>>> #
>>>> # If you would like to submit a bug report, please visit:
>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>> #
>>>> |
>>>> |======================================================
>>>> ||
>>>> ||- Ioi|
>>>>
>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>> Hi Ioi, David,
>>>>>
>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>> stand-alone test case that doesn't require truncating JAR files in
>>>>>> the JDK:||
>>>>>> ||
>>>>>> ||=========================||
>>>>>> ||/*||
>>>>>> ||javac test2.java||
>>>>>> ||rm -f foo.jar||
>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>> ||touch foo.jar||
>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>> ||*/||
>>>>>> ||
>>>>>> ||public class test2 {||
>>>>>> ||    public static void main(String args[]) {||
>>>>>> ||        try {||
>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>> ||        } catch (Throwable t) {||
>>>>>> ||            t.printStackTrace();||
>>>>>> ||        }||
>>>>>> ||    }||
>>>>>> ||}||
>>>>>> ||=========================||
>>>>>> | |
>>>>>> ||JDK6 works fine, but JDK7 would crash with the second "java -cp .
>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>> |
>>>>> |I saw crash with the latest 6 update release with both test cases.
>>>>> The crash seems to be at the same spot.
>>>>> |
>>>>>> |||
>>>>>> ||So I think the correct fix is to restore the JDK6 behavior (not
>>>>>> sure if it's already the same with your patch, but worth checking),
>>>>>> and also add a new jtreg test into hotspot.||
>>>>>> |
>>>>> |I checked the jdk 6 code and those 3 methods which I changed look 
>>>>> the
>>>>> same as jdk 8.
>>>>> Sure, I can add a jtreg test.
>>>>> |
>>>>>> |||
>>>>>> ||Thanks||
>>>>>> ||- Ioi||
>>>>>> ||
>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>> |
>>>>>>> |Hi Calvin, ||
>>>>>>> | |
>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>> declared with a last parameter of TRAPS and called with a CHECK_
>>>>>>> macro. The way this code is written it does not seem to expect any
>>>>>>> exceptions to be possible. I would check with Karen on this. ||
>>>>>>> |
>>>>> |I was thinking about that but that would involves a bit more 
>>>>> changes.
>>>>> I can give it a try.
>>>>> |
>>>>>>> || |
>>>>>>> ||This addition seems unused: ||
>>>>>>> | |
>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>> |
>>>>> |It is required for the THROW_MSG().
>>>>> It won't be needed if the method is declared with TRAPS as the last
>>>>> parameter (I think).
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>>> |
>>>>>>> || |
>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing
>>>>>>> exceptions - don't know what the thought process was there :) ||
>>>>>>> | |
>>>>>>> ||David ||
>>>>>>> | |
>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>> |
>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce 
>>>>>>>> similar
>>>>>>>> crash ||
>>>>>>>> ||by trying to load a class from an empty jar which is in the ||
>>>>>>>> ||bootclasspath. The following program can trigger the crash if 
>>>>>>>> the ||
>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>> | |
>>>>>>>> ||public class TestForName { ||
>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>> ||         try { ||
>>>>>>>> ||             Class cls =
>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>> ||             System.out.println("Class = " + cls.getName()); ||
>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>> ||         } ||
>>>>>>>> ||     } ||
>>>>>>>> ||} ||
>>>>>>>> | |
>>>>>>>> ||The fix also changes the assert() in
>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>>>>> above test ||
>>>>>>>> ||scenario. ||
>>>>>>>> | |
>>>>>>>> ||With the fix, the following ClassNotFoundException will be 
>>>>>>>> thrown ||
>>>>>>>> ||instead of a crash: ||
>>>>>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>>>>>> ||         at 
>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>> ||         at 
>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>> ||         at java.security.AccessController.doPrivileged(Native
>>>>>>>> Method) ||
>>>>>>>> ||         at
>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>> ||         at 
>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>> ||         at
>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>>>>>> ||         at 
>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>> | |
>>>>>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>> | |
>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>> | |
>>>>>>>> ||Tests: ||
>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>> | |
>>>>>>>> ||thanks, ||
>>>>>>>> ||Calvin ||
>>>>>>>> | |
>>>>>>>> | |
>>>>>>>> |
>>>>>> |
>>>>>> |
>>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/a67a0c45/attachment-0001.html 

From coleen.phillimore at oracle.com  Fri Aug  9 15:26:21 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 09 Aug 2013 18:26:21 -0400
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <52055DAF.90707@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
Message-ID: <52056C8D.2060808@oracle.com>


Hi Jiangli,
I thought this was reviewed already.   I've just reviewed it.

http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/src/share/vm/classfile/classFileParser.hpp.udiff.html 
<http://cr.openjdk.java.net/%7Ejiangli/8021948/webrev.00/src/share/vm/classfile/classFileParser.hpp.udiff.html>

On 8/9/2013 5:22 PM, Jiangli Zhou wrote:
> Hi,
>
> Could anyone help me review this?
>
> Thanks,
> Jiangli
>
> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>> Hi,
>>
>> Please review following change for JDK-8021948 
>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>
>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>
>> Both InstanceKlass::_source_file_name and 
>> InstanceKlass::_generic_signature were pointers to Symbol. They are 
>> now indexes to constant pool entries. Both fields are now u2 type, 
>> and co-located with other non-pointer type fields for more efficient 
>> alignment on 64-bit machine. On 32-bit machine, the change saves 
>> 4bytes for each class.
>>
>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>> nsk.stress.testlist and nsk.jvmti.testlist.
>>
>> Thanks,
>> Jiangli
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/09ba37bd/attachment.html 

From coleen.phillimore at oracle.com  Fri Aug  9 15:27:32 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 09 Aug 2013 18:27:32 -0400
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <52055DAF.90707@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
Message-ID: <52056CD4.8000503@oracle.com>


Hit send too soon.   Can you line up functions in :
http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/src/share/vm/classfile/classFileParser.hpp.udiff.html 
<http://cr.openjdk.java.net/%7Ejiangli/8021948/webrev.00/src/share/vm/classfile/classFileParser.hpp.udiff.html>

Everything else looks good.
Thanks,
Coleen


On 8/9/2013 5:22 PM, Jiangli Zhou wrote:
> Hi,
>
> Could anyone help me review this?
>
> Thanks,
> Jiangli
>
> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>> Hi,
>>
>> Please review following change for JDK-8021948 
>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>
>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>
>> Both InstanceKlass::_source_file_name and 
>> InstanceKlass::_generic_signature were pointers to Symbol. They are 
>> now indexes to constant pool entries. Both fields are now u2 type, 
>> and co-located with other non-pointer type fields for more efficient 
>> alignment on 64-bit machine. On 32-bit machine, the change saves 
>> 4bytes for each class.
>>
>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>> nsk.stress.testlist and nsk.jvmti.testlist.
>>
>> Thanks,
>> Jiangli
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/6ac97f45/attachment.html 

From jiangli.zhou at oracle.com  Fri Aug  9 15:31:31 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 09 Aug 2013 15:31:31 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <52056CD4.8000503@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<52056CD4.8000503@oracle.com>
Message-ID: <52056DC3.4010900@oracle.com>

Hi Coleen,

Will do. Thanks for the review!

Jiangli

On 08/09/2013 03:27 PM, Coleen Phillimore wrote:
>
> Hit send too soon.   Can you line up functions in :
> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/src/share/vm/classfile/classFileParser.hpp.udiff.html 
> <http://cr.openjdk.java.net/%7Ejiangli/8021948/webrev.00/src/share/vm/classfile/classFileParser.hpp.udiff.html>
>
> Everything else looks good.
> Thanks,
> Coleen
>
>
> On 8/9/2013 5:22 PM, Jiangli Zhou wrote:
>> Hi,
>>
>> Could anyone help me review this?
>>
>> Thanks,
>> Jiangli
>>
>> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>>> Hi,
>>>
>>> Please review following change for JDK-8021948 
>>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>>
>>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>>
>>> Both InstanceKlass::_source_file_name and 
>>> InstanceKlass::_generic_signature were pointers to Symbol. They are 
>>> now indexes to constant pool entries. Both fields are now u2 type, 
>>> and co-located with other non-pointer type fields for more efficient 
>>> alignment on 64-bit machine. On 32-bit machine, the change saves 
>>> 4bytes for each class.
>>>
>>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>>> nsk.stress.testlist and nsk.jvmti.testlist.
>>>
>>> Thanks,
>>> Jiangli
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/2a7c6f9a/attachment.html 

From coleen.phillimore at oracle.com  Fri Aug  9 15:33:43 2013
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 09 Aug 2013 22:33:43 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022452: Hotspot needs to know about
	Windows 8.1 and Windows Server 2012 R2
Message-ID: <20130809223345.B2F6148775@hg.openjdk.java.net>

Changeset: 98aa538fd97e
Author:    mikael
Date:      2013-08-09 09:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/98aa538fd97e

8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2
Summary: Add support for recognizing Windows 8.1 and Server 2012 R2 and minor cleanup
Reviewed-by: coleenp, dsamersoff

! src/os/windows/vm/os_windows.cpp


From ioi.lam at oracle.com  Fri Aug  9 17:39:21 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 09 Aug 2013 17:39:21 -0700
Subject: RFR (XS) 8022740 - Visual 2008 IDE build is broken
Message-ID: <52058BB9.50207@oracle.com>

|Please review a very small fix:||
||
||http://cr.openjdk.java.net/~iklam/8022740/vs2008_ide_001/||
||
||Bug: Visual 2008 IDE build is broken||
||
||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022740||
||    https://jbs.oracle.com/bugs/browse/JDK-8022740||
||
||Summary of fix:||
||
||    Apparently some refactoring (7163863??) of the VC project creator 
has||
||    not been tested with VS2008.||
||
||    I made some minor fixes. I verified that VS2008 works.||
||
||    I changed one file related to VS2010. Could someone with VS2010 
give it a try?||
||||
||Thanks||
||- Ioi||
||
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/948cc4a6/attachment.html 

From daniel.daugherty at oracle.com  Fri Aug  9 18:47:24 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Sat, 10 Aug 2013 01:47:24 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 15 new changesets
Message-ID: <20130810014757.DE1694877F@hg.openjdk.java.net>

Changeset: cd25d3be91c5
Author:    vladidan
Date:      2013-08-06 20:01 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cd25d3be91c5

8012144: multiple SIGSEGVs fails on staxf
Summary: Forward port of 7u change to add additional fence() on RMO platforms, with a load_acquire on all platforms
Reviewed-by: dholmes, kvn

! src/share/vm/utilities/taskqueue.hpp

Changeset: f5bed20f2492
Author:    dholmes
Date:      2013-08-08 08:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f5bed20f2492

Merge


Changeset: 79a5283f4595
Author:    iignatyev
Date:      2013-07-29 11:54 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/79a5283f4595

8021120: TieredCompilation can be enabled even if TIERED is undefined
Reviewed-by: kvn, dholmes

! src/share/vm/runtime/arguments.cpp

Changeset: 8d77d02828d9
Author:    twisti
Date:      2013-07-29 16:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8d77d02828d9

8016474: Crash in sun.reflect.UnsafeObjectFieldAccessorImpl.get
Summary: C1's GetUnsafeObject G1 pre-barrier uses the wrong type to read the klass pointer.
Reviewed-by: iveresov, kvn

! src/share/vm/c1/c1_LIRGenerator.cpp
+ test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java

Changeset: 446cb5d25d03
Author:    anoll
Date:      2013-08-01 16:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/446cb5d25d03

8020531: Test compiler/codecache/CheckUpperLimit.java fails when memory limited
Summary: Removed part of the test that required the VM to start up with -XX:ReservedCodeCacheSize=2048m
Reviewed-by: kvn, rbackman

! test/compiler/codecache/CheckUpperLimit.java

Changeset: 6e04c193845f
Author:    anoll
Date:      2013-08-02 10:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6e04c193845f

8021301: better event messages
Summary: made event messages better readable
Reviewed-by: kvn, rbackman

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/utilities/exceptions.cpp

Changeset: 5e0b3d7df485
Author:    rbackman
Date:      2013-08-05 17:15 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5e0b3d7df485

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 71526a36ebb4
Author:    twisti
Date:      2013-08-05 15:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/71526a36ebb4

8022029: GetUnsafeObjectG1PreBarrier fails on 32-bit with: Unrecognized VM option 'ObjectAlignmentInBytes=32'
Reviewed-by: kvn

! test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java

Changeset: dadf62510ae4
Author:    rbackman
Date:      2013-08-08 23:49 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dadf62510ae4

Merge


Changeset: b9a927798f12
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b9a927798f12

Added tag jdk8-b102 for changeset c4697c1c4484

! .hgtags

Changeset: 7f55137d6aa8
Author:    amurillo
Date:      2013-08-09 01:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7f55137d6aa8

Merge

- test/runtime/7196045/Test7196045.java
- test/runtime/8000968/Test8000968.sh

Changeset: 6f9be7f87b96
Author:    amurillo
Date:      2013-08-09 01:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6f9be7f87b96

Added tag hs25-b45 for changeset 7f55137d6aa8

! .hgtags

Changeset: 39127bb12d32
Author:    amurillo
Date:      2013-08-09 01:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/39127bb12d32

8022688: new hotspot build - hs25-b46
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ed7c17e7d45b
Author:    dcubed
Date:      2013-08-09 13:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ed7c17e7d45b

Merge


Changeset: 7b03590c334b
Author:    dcubed
Date:      2013-08-09 15:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7b03590c334b

Merge



From calvin.cheung at oracle.com  Fri Aug  9 21:13:33 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 09 Aug 2013 21:13:33 -0700
Subject: RFR (XS) 8022740 - Visual 2008 IDE build is broken
In-Reply-To: <52058BB9.50207@oracle.com>
References: <52058BB9.50207@oracle.com>
Message-ID: <5205BDED.4050309@oracle.com>

Hi Ioi,

I've tried your patch on vs2010 and it seems working fine.
I was able to generate a project file and used vs2010 to open the 
project file.
So I think your fix is good. (I'm not a Reviewer)

Calvin

On 8/9/2013 5:39 PM, Ioi Lam wrote:
> |Please review a very small fix:||
> ||
> ||http://cr.openjdk.java.net/~iklam/8022740/vs2008_ide_001/||
> ||
> ||Bug: Visual 2008 IDE build is broken||
> ||
> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022740||
> ||https://jbs.oracle.com/bugs/browse/JDK-8022740||
> ||
> ||Summary of fix:||
> ||
> ||    Apparently some refactoring (7163863??) of the VC project 
> creator has||
> ||    not been tested with VS2008.||
> ||
> ||    I made some minor fixes. I verified that VS2008 works.||
> ||
> ||    I changed one file related to VS2010. Could someone with VS2010 
> give it a try?||
> ||||
> ||Thanks||
> ||- Ioi||
> ||
> | 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130809/c72a9f62/attachment.html 

From daniel.daugherty at oracle.com  Sat Aug 10 10:07:15 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Sat, 10 Aug 2013 11:07:15 -0600
Subject: RFR (XS) 8022740 - Visual 2008 IDE build is broken
In-Reply-To: <52058BB9.50207@oracle.com>
References: <52058BB9.50207@oracle.com>
Message-ID: <52067343.7050604@oracle.com>

On 8/9/13 6:39 PM, Ioi Lam wrote:
> |Please review a very small fix:||
> ||
> ||http://cr.openjdk.java.net/~iklam/8022740/vs2008_ide_001/||
> |
|
Thumbs up!


make/windows/projectfiles/common/Makefile
     No comments.

src/share/tools/ProjectCreator/FileTreeCreator.java
     No comments.

src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
     No comments.

src/share/tools/ProjectCreator/FileTreeCreatorVC7.java
     No comments.

src/share/tools/ProjectCreator/WinGammaPlatformVC7.java|
     You should indent line 145 a bit since you put that
     call in an if-statement.


> |||Bug: Visual 2008 IDE build is broken||
> ||
> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022740||
> ||https://jbs.oracle.com/bugs/browse/JDK-8022740||
> ||
> ||Summary of fix:||
> ||
> ||    Apparently some refactoring (7163863??) of the VC project 
> creator has||
> ||    not been tested with VS2008.||
> |

|I don't think that VS2008 was ever fully tested/used as a build
environment for any HSX release. This means that you may run into
strange failures that don't happen with VS2003 or VS2010. Yes, I'm
reasonably sure that we didn't fully test or use VS2005 either.

Dan



|
> |||
> ||    I made some minor fixes. I verified that VS2008 works.||
> ||
> ||    I changed one file related to VS2010. Could someone with VS2010 
> give it a try?||
> ||||
> ||Thanks||
> ||- Ioi||
> ||
> | 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130810/af42563a/attachment.html 

From tim.bell at oracle.com  Sat Aug 10 11:08:06 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Sat, 10 Aug 2013 11:08:06 -0700
Subject: RFR (XS) 8022740 - Visual 2008 IDE build is broken
In-Reply-To: <52067343.7050604@oracle.com>
References: <52058BB9.50207@oracle.com> <52067343.7050604@oracle.com>
Message-ID: <52068186.1040609@oracle.com>

On 08/10/13 10:07 AM, Daniel D. Daugherty wrote:
> |I don't think that VS2008 was ever fully tested/used as a build
> environment for any HSX release. This means that you may run into
> strange failures that don't happen with VS2003 or VS2010. Yes, I'm
> reasonably sure that we didn't fully test or use VS2005 either.|

We got the hotspot build working with VS2008 fairly early in the 
project.  I don't recall who helped me, but I'm sure I got help from VM 
engineers on that:

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

After a long list of fixes in other areas of JDK7 while trying to get 
the entire product to build, there was no end in sight, and the project 
was put on hold until VS2010 came along.  See bug# 6523947 and the 
related reports listed there:

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

Tim


From ioi.lam at oracle.com  Sat Aug 10 11:25:35 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Sat, 10 Aug 2013 11:25:35 -0700
Subject: RFR (XS) 8022740 - Visual 2008 IDE build is broken
In-Reply-To: <52067343.7050604@oracle.com>
References: <52058BB9.50207@oracle.com> <52067343.7050604@oracle.com>
Message-ID: <5206859F.8070301@oracle.com>

Thanks Dan & Calvin for the review. I will fix the indentation and push.

- Ioi

On 08/10/2013 10:07 AM, Daniel D. Daugherty wrote:
> On 8/9/13 6:39 PM, Ioi Lam wrote:
>> |Please review a very small fix:||
>> ||
>> ||http://cr.openjdk.java.net/~iklam/8022740/vs2008_ide_001/||
>> |
> |
> Thumbs up!
>
>
> make/windows/projectfiles/common/Makefile
>     No comments.
>
> src/share/tools/ProjectCreator/FileTreeCreator.java
>     No comments.
>
> src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
>     No comments.
>
> src/share/tools/ProjectCreator/FileTreeCreatorVC7.java
>     No comments.
>
> src/share/tools/ProjectCreator/WinGammaPlatformVC7.java|
>     You should indent line 145 a bit since you put that
>     call in an if-statement.
>
>
>> |||Bug: Visual 2008 IDE build is broken||
>> ||
>> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022740||
>> ||https://jbs.oracle.com/bugs/browse/JDK-8022740||
>> ||
>> ||Summary of fix:||
>> ||
>> ||    Apparently some refactoring (7163863??) of the VC project 
>> creator has||
>> ||    not been tested with VS2008.||
>> |
>
> |I don't think that VS2008 was ever fully tested/used as a build
> environment for any HSX release. This means that you may run into
> strange failures that don't happen with VS2003 or VS2010. Yes, I'm
> reasonably sure that we didn't fully test or use VS2005 either.
>
> Dan
>
>
>
> |
>> |||
>> ||    I made some minor fixes. I verified that VS2008 works.||
>> ||
>> ||    I changed one file related to VS2010. Could someone with VS2010 
>> give it a try?||
>> ||||
>> ||Thanks||
>> ||- Ioi||
>> ||
>> | 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130810/1143387e/attachment.html 

From ioi.lam at oracle.com  Sat Aug 10 13:54:47 2013
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Sat, 10 Aug 2013 20:54:47 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022740: Visual 2008 IDE build is broken
Message-ID: <20130810205451.E468E48793@hg.openjdk.java.net>

Changeset: bd0e82136b03
Author:    iklam
Date:      2013-08-10 10:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bd0e82136b03

8022740: Visual 2008 IDE build is broken
Summary: Fixed project generation code, and added warning to upgrade to VS 2008 SP1.
Reviewed-by: dcubed, ccheung

! make/windows/projectfiles/common/Makefile
! src/share/tools/ProjectCreator/FileTreeCreator.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC7.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java


From yumin.qi at oracle.com  Sun Aug 11 16:36:22 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Sun, 11 Aug 2013 16:36:22 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
Message-ID: <52081FF6.4040205@oracle.com>

Hi, all

   I would like to have your review for

http://cr.openjdk.java.net/~minqi/8020962/webrev0/ 
<http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>

Description: When JVM crashed, we also want to check the application 
class files especially we got core file from customers.  The aftermath 
analysis will benefit from all loaded java classes available. In this 
change, spawn another process running SA to do the job when JVM crashes, 
this way also avoid further messing up with the error report which 
already in
signal handler.

Note: The test has done with following two bugs worked around:
   8022655: ClassDump ignored jarStream setting (This will be fixed and 
integrated by Kevin Walls soon)
   8011888: sa.js: TypeError: [object JSAdapter] has no such function 
"__has__" (Not know when it will be integrated)
   That is, without those two fixed, the jars of loaded classes will not 
be successfully dumped.
   Also, on MacOS it requires security access permission to attach to 
another process, so omit doing so. To get loaded jar file
s, with core file available (on all platforms), one can (only after this 
change) do

   $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar 
sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile


Thanks
Yumin

From david.holmes at oracle.com  Sun Aug 11 18:33:15 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Mon, 12 Aug 2013 01:33:15 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 24 new changesets
Message-ID: <20130812013404.13D3A487A4@hg.openjdk.java.net>

Changeset: 9bd314787fad
Author:    mseledtsov
Date:      2013-08-01 22:15 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9bd314787fad

8020614: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Summary: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Reviewed-by: kvn, ctornqvi, dholmes

+ test/testlibrary/OutputAnalyzerReportingTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java

Changeset: c01913206da5
Author:    ctornqvi
Date:      2013-08-01 22:20 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c01913206da5

8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle
Summary: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle
Reviewed-by: coleenp, sspitsyn

! src/share/vm/services/management.cpp

Changeset: 81e0f17ade64
Author:    ctornqvi
Date:      2013-08-01 22:25 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/81e0f17ade64

8009407: runtime/8000968/Test8000968.sh has incorrect check for proper config
Summary: runtime/8000968/Test8000968.sh has incorrect check for proper config
Reviewed-by: coleenp, mseledtsov, sspitsyn, hseigel

- test/runtime/8000968/Test8000968.sh
+ test/runtime/CompressedOops/CompressedKlassPointerAndOops.java

Changeset: 32e3bada0978
Author:    kevinw
Date:      2013-08-02 12:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/32e3bada0978

8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str()
Reviewed-by: mgerdin, fparain, dcubed

! src/share/vm/services/gcNotifier.cpp

Changeset: dee4c330acd4
Author:    dcubed
Date:      2013-08-02 08:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/dee4c330acd4

Merge

- test/runtime/8000968/Test8000968.sh

Changeset: fa57c8104b76
Author:    ctornqvi
Date:      2013-08-02 18:12 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/fa57c8104b76

8009585: test/runtime/7196045 times out
Summary: test/runtime/7196045 times out
Reviewed-by: dholmes, mseledtsov

- test/runtime/7196045/Test7196045.java
+ test/runtime/InternalApi/ThreadCpuTimesDeadlock.java

Changeset: 0f209afdfcf8
Author:    ctornqvi
Date:      2013-08-02 18:26 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0f209afdfcf8

Merge


Changeset: d02de8cac823
Author:    ctornqvi
Date:      2013-08-02 22:34 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d02de8cac823

Merge

- test/runtime/7196045/Test7196045.java

Changeset: e0379d5ba5d2
Author:    kevinw
Date:      2013-08-05 10:27 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e0379d5ba5d2

8021444: SA: ClassDump.run() should not ignore existing ClassFilter.
Reviewed-by: minqi, poonam

! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java

Changeset: b67604b59546
Author:    hseigel
Date:      2013-08-04 16:30 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b67604b59546

7073961: [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 X65
Summary: Added a x86 64-bit Solaris shared library and rewrote test in Java
Reviewed-by: dholmes, ctornqvi

! test/testlibrary/com/oracle/java/testlibrary/Platform.java

Changeset: 9064e3a19525
Author:    hseigel
Date:      2013-08-05 08:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9064e3a19525

Merge

- test/runtime/7196045/Test7196045.java
- test/runtime/8000968/Test8000968.sh

Changeset: 22a5aff0df0b
Author:    dsamersoff
Date:      2013-08-06 14:28 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/22a5aff0df0b

8019396: SA-JDI OSThread class initialization throws an exception
Summary: Method sun.jvm.hotspot.runtime.OSThread.initialize throws a sun.jvm.hotspot.types.WrongTypeException
Reviewed-by: dholmes, mgerdin

! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java

Changeset: f5bed20f2492
Author:    dholmes
Date:      2013-08-08 08:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f5bed20f2492

Merge


Changeset: 79a5283f4595
Author:    iignatyev
Date:      2013-07-29 11:54 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/79a5283f4595

8021120: TieredCompilation can be enabled even if TIERED is undefined
Reviewed-by: kvn, dholmes

! src/share/vm/runtime/arguments.cpp

Changeset: 8d77d02828d9
Author:    twisti
Date:      2013-07-29 16:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8d77d02828d9

8016474: Crash in sun.reflect.UnsafeObjectFieldAccessorImpl.get
Summary: C1's GetUnsafeObject G1 pre-barrier uses the wrong type to read the klass pointer.
Reviewed-by: iveresov, kvn

! src/share/vm/c1/c1_LIRGenerator.cpp
+ test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java

Changeset: 446cb5d25d03
Author:    anoll
Date:      2013-08-01 16:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/446cb5d25d03

8020531: Test compiler/codecache/CheckUpperLimit.java fails when memory limited
Summary: Removed part of the test that required the VM to start up with -XX:ReservedCodeCacheSize=2048m
Reviewed-by: kvn, rbackman

! test/compiler/codecache/CheckUpperLimit.java

Changeset: 6e04c193845f
Author:    anoll
Date:      2013-08-02 10:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6e04c193845f

8021301: better event messages
Summary: made event messages better readable
Reviewed-by: kvn, rbackman

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/utilities/exceptions.cpp

Changeset: 5e0b3d7df485
Author:    rbackman
Date:      2013-08-05 17:15 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5e0b3d7df485

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 71526a36ebb4
Author:    twisti
Date:      2013-08-05 15:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/71526a36ebb4

8022029: GetUnsafeObjectG1PreBarrier fails on 32-bit with: Unrecognized VM option 'ObjectAlignmentInBytes=32'
Reviewed-by: kvn

! test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java

Changeset: dadf62510ae4
Author:    rbackman
Date:      2013-08-08 23:49 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/dadf62510ae4

Merge


Changeset: b9a927798f12
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b9a927798f12

Added tag jdk8-b102 for changeset c4697c1c4484

! .hgtags

Changeset: 7f55137d6aa8
Author:    amurillo
Date:      2013-08-09 01:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7f55137d6aa8

Merge

- test/runtime/7196045/Test7196045.java
- test/runtime/8000968/Test8000968.sh

Changeset: 6f9be7f87b96
Author:    amurillo
Date:      2013-08-09 01:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6f9be7f87b96

Added tag hs25-b45 for changeset 7f55137d6aa8

! .hgtags

Changeset: 39127bb12d32
Author:    amurillo
Date:      2013-08-09 01:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/39127bb12d32

8022688: new hotspot build - hs25-b46
Reviewed-by: jcoomes

! make/hotspot_version


From david.holmes at oracle.com  Sun Aug 11 22:40:49 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Aug 2013 15:40:49 +1000
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52056910.8010005@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com>
Message-ID: <52087561.4000409@oracle.com>

Hi Calvin,

I don't think this works. As I said previously the expectations of this 
code with regard to Java exceptions seems to be that it doesn't expect 
them at all. If you are using TRAPS etc then it should be used all the 
way through the call chain. What we have now is this call sequence:

void ClassLoader::initialize() {
   assert(_package_hash_table == NULL, "should have been initialized by 
now.");
   EXCEPTION_MARK;
   ...
   setup_bootstrap_search_path();
     -> update_class_path_entry_list(path, false);
       ->  create_class_path_entry((char *)path, st, &new_entry, 
LazyBootClassLoader, CHECK);

So if we return after the call to create_class_path_entry with an 
exception pending we will crash when we hit the EXCEPTION_MARK.

It may be that the EXCEPTION_MARK needs replacing with an explicit 
exception check and a vm_exit_during_initialization, if this exception 
can readily occur at runtime. But further analysis of all this code 
needs to be undertaken.

David
-----

On 10/08/2013 8:11 AM, Calvin Cheung wrote:
> I've updated the webrev with 2 changes:
> 1) added the TRAPS as the last parameter to the
> create_class_path_entry() method;
> 2) added a jtreg test case.
>
> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>
> Please take a look again.
>
> One more response in-lined below...
>
> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>> |I found one version of JDK7 that does not crash:||
>> ||
>> sc11136754 ~$
>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java
>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>> Error occurred during initialization of VM
>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>> |
>
> |I noticed that it started breaking in 7u40 b01; it was still working
> with 7u25.
> It may have something to do with when the set_init_completed() is called:
> ExceptionMark::~ExceptionMark() {
>    if (_thread->has_pending_exception()) {
>      Handle exception(_thread, _thread->pending_exception());
>      _thread->clear_pending_exception(); // Needed to avoid infinite
> recursion
>      if (is_init_completed()) {
>        exception->print();
>        fatal("ExceptionMark destructor expects no pending exceptions");
>      } else {
>        vm_exit_during_initialization(exception);
>      }
>    }
> }
>
> Before 7u40, I think the code path got to the "else" branch of
> ~ExceptionMark() and we just printed an error and exit.
>
> set_init_completed() is only called from Threads::create_vm() and that
> method didn't change much between 7u25 and 7u40 except for some NMT
> initialization - MemTracker::bootstrap_single_thread(),
> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>
> Debugging with hs25, the set_init_completed() always happened before
> create_class_path_entry() and both calls were done within the same
> thread - "vm startup".
>
> thanks,
> Calvin
>
>
> |
>> |||
>> ||
>> ||- Ioi
>> |
>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>> |I found an official version that's closest to the Redhat version
>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>> crashes.||
>>> ||
>>> ||sc11136754 ~$
>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>> ||java version "1.6.0_25"||
>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>> ||
>>> ||java.lang.ClassNotFoundException ||
>>> || - klass: 'java/lang/ClassNotFoundException'||
>>> ||#||
>>> ||# A fatal error has been detected by the Java Runtime Environment:||
>>> ||#||
>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>> tid=140608485558016||
>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>> exceptions||
>>> ||#||
>>> ||# JRE version: 6.0_25-b06||
>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>> linux-amd64 compressed oops)||
>>> ||# An error report file with more information is saved as:||
>>> ||# /home/iklam/hs_err_pid29955.log||
>>> ||#||
>>> ||# If you would like to submit a bug report, please visit:||
>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>> ||#||
>>> ||Aborted (core dumped)||
>>> |
>>> - Ioi
>>>
>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>> apparently
>>>>> works differently
>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed this in
>>>>> their
>>>>> own repo??||
>>>>
>>>> Their hotspot version is much later - hs20 vs hs17
>>>>
>>>> David
>>>> -----
>>>>
>>>>> ||
>>>>> |
>>>>> |==OEL6================================================
>>>>> ||
>>>>> ||sc11136754 ~$ uname -a||
>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>> ||sc11136754 ~$ type java||
>>>>> ||java is hashed (/usr/bin/java)||
>>>>> ||sc11136754 ~$ java -version||
>>>>> ||java version "1.6.0_22"||
>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>> test2||
>>>>> ||Error occurred during initialization of VM||
>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>> foo.jar||
>>>>> ||
>>>>> ==OFFICIAL============================================
>>>>> ||
>>>>> sc11136754 ~$ /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>> java version "1.6.0_22"
>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>
>>>>> #
>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>> #
>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, tid=140510319580928
>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>> #
>>>>> # JRE version: 6.0_22-b04
>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>> linux-amd64 )
>>>>> # An error report file with more information is saved as:
>>>>> # /home/iklam/hs_err_pid25167.log
>>>>> #
>>>>> # If you would like to submit a bug report, please visit:
>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>> #
>>>>> |
>>>>> |======================================================
>>>>> ||
>>>>> ||- Ioi|
>>>>>
>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>> Hi Ioi, David,
>>>>>>
>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>> stand-alone test case that doesn't require truncating JAR files in
>>>>>>> the JDK:||
>>>>>>> ||
>>>>>>> ||=========================||
>>>>>>> ||/*||
>>>>>>> ||javac test2.java||
>>>>>>> ||rm -f foo.jar||
>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>> ||touch foo.jar||
>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>> ||*/||
>>>>>>> ||
>>>>>>> ||public class test2 {||
>>>>>>> ||    public static void main(String args[]) {||
>>>>>>> ||        try {||
>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>> ||        } catch (Throwable t) {||
>>>>>>> ||            t.printStackTrace();||
>>>>>>> ||        }||
>>>>>>> ||    }||
>>>>>>> ||}||
>>>>>>> ||=========================||
>>>>>>> | |
>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second "java -cp .
>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>> |
>>>>>> |I saw crash with the latest 6 update release with both test cases.
>>>>>> The crash seems to be at the same spot.
>>>>>> |
>>>>>>> |||
>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior (not
>>>>>>> sure if it's already the same with your patch, but worth checking),
>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>> |
>>>>>> |I checked the jdk 6 code and those 3 methods which I changed look
>>>>>> the
>>>>>> same as jdk 8.
>>>>>> Sure, I can add a jtreg test.
>>>>>> |
>>>>>>> |||
>>>>>>> ||Thanks||
>>>>>>> ||- Ioi||
>>>>>>> ||
>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>> |
>>>>>>>> |Hi Calvin, ||
>>>>>>>> | |
>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>> declared with a last parameter of TRAPS and called with a CHECK_
>>>>>>>> macro. The way this code is written it does not seem to expect any
>>>>>>>> exceptions to be possible. I would check with Karen on this. ||
>>>>>>>> |
>>>>>> |I was thinking about that but that would involves a bit more
>>>>>> changes.
>>>>>> I can give it a try.
>>>>>> |
>>>>>>>> || |
>>>>>>>> ||This addition seems unused: ||
>>>>>>>> | |
>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>> |
>>>>>> |It is required for the THROW_MSG().
>>>>>> It won't be needed if the method is declared with TRAPS as the last
>>>>>> parameter (I think).
>>>>>>
>>>>>> thanks,
>>>>>> Calvin
>>>>>> |
>>>>>>>> || |
>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to throwing
>>>>>>>> exceptions - don't know what the thought process was there :) ||
>>>>>>>> | |
>>>>>>>> ||David ||
>>>>>>>> | |
>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>> |
>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>> similar
>>>>>>>>> crash ||
>>>>>>>>> ||by trying to load a class from an empty jar which is in the ||
>>>>>>>>> ||bootclasspath. The following program can trigger the crash if
>>>>>>>>> the ||
>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>> | |
>>>>>>>>> ||public class TestForName { ||
>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>> ||         try { ||
>>>>>>>>> ||             Class cls =
>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>> ||             System.out.println("Class = " + cls.getName()); ||
>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>> ||         } ||
>>>>>>>>> ||     } ||
>>>>>>>>> ||} ||
>>>>>>>>> | |
>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>>>>>> above test ||
>>>>>>>>> ||scenario. ||
>>>>>>>>> | |
>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>> thrown ||
>>>>>>>>> ||instead of a crash: ||
>>>>>>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>>>>>>> ||         at
>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>> ||         at
>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>> ||         at java.security.AccessController.doPrivileged(Native
>>>>>>>>> Method) ||
>>>>>>>>> ||         at
>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>> ||         at
>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>> ||         at
>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>>>>>>> ||         at
>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>> | |
>>>>>>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>> | |
>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>> | |
>>>>>>>>> ||Tests: ||
>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>> | |
>>>>>>>>> ||thanks, ||
>>>>>>>>> ||Calvin ||
>>>>>>>>> | |
>>>>>>>>> | |
>>>>>>>>> |
>>>>>>> |
>>>>>>> |
>>>>>>
>>>>>
>>>
>>
>

From david.holmes at oracle.com  Sun Aug 11 22:56:29 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Aug 2013 15:56:29 +1000
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <52081FF6.4040205@oracle.com>
References: <52081FF6.4040205@oracle.com>
Message-ID: <5208790D.9010309@oracle.com>

Hi Yumin,

Note that the SA is only present in a full JDK, not a JRE (full or 
compact profile).

I have quite a few concerns with this:

We already do a lot of things that are not valid to be done from a 
signal handling context but this really takes that to an extreme. Doing 
fork-exec from a signal handler seems like a recipe for disaster (Note 
the existing onError facility is typically used for synchronous failures.)

The idea of launching a second VM to try and query a VM that has crashed 
also seems somewhat problematic:
- What mechanism will the SA try to use to query the VM?
- What if the state of the crashed VM stops the SA from being able to 
attach properly (ie both processes hang)?
- What if it the SA also crashes, will it launch a third VM then a 
fourth etc?

Also what is the nature of this dump? How big is it? Where will it go?

Thanks,
David

On 12/08/2013 9:36 AM, Yumin Qi wrote:
> Hi, all
>
>    I would like to have your review for
>
> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>
> Description: When JVM crashed, we also want to check the application
> class files especially we got core file from customers.  The aftermath
> analysis will benefit from all loaded java classes available. In this
> change, spawn another process running SA to do the job when JVM crashes,
> this way also avoid further messing up with the error report which
> already in
> signal handler.
>
> Note: The test has done with following two bugs worked around:
>    8022655: ClassDump ignored jarStream setting (This will be fixed and
> integrated by Kevin Walls soon)
>    8011888: sa.js: TypeError: [object JSAdapter] has no such function
> "__has__" (Not know when it will be integrated)
>    That is, without those two fixed, the jars of loaded classes will not
> be successfully dumped.
>    Also, on MacOS it requires security access permission to attach to
> another process, so omit doing so. To get loaded jar file
> s, with core file available (on all platforms), one can (only after this
> change) do
>
>    $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>
>
> Thanks
> Yumin

From thomas.schatzl at oracle.com  Mon Aug 12 01:53:41 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 12 Aug 2013 10:53:41 +0200
Subject: RFR (XXS): 8022784 TaskQueue misses minimal documentation and
	references for analysis
Message-ID: <1376297621.11034.4.camel@cirrus>

Hi all,

  need two quick reviews for the following change; the discussions for
"JDK-8006971 More missing barriers in taskqueues for RMO architectures"
showed that there is need for some minimal overview and references for
the taskqueue implementation.

This CR adds general documentation, and more importantly, references to
papers about the implementation.

Webrev:
http://cr.openjdk.java.net/~tschatzl/8022784/webrev/

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

JIRA:
https://jbs.oracle.com/bugs/browse/JDK-8022784

Testing:
N/A

Hth,
Thomas


From david.holmes at oracle.com  Mon Aug 12 04:50:29 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Aug 2013 21:50:29 +1000
Subject: RFR (XXS): 8022784 TaskQueue misses minimal documentation and
	references for analysis
In-Reply-To: <1376297621.11034.4.camel@cirrus>
References: <1376297621.11034.4.camel@cirrus>
Message-ID: <5208CC05.5030508@oracle.com>

Okay.

Thanks,
David

On 12/08/2013 6:53 PM, Thomas Schatzl wrote:
> Hi all,
>
>    need two quick reviews for the following change; the discussions for
> "JDK-8006971 More missing barriers in taskqueues for RMO architectures"
> showed that there is need for some minimal overview and references for
> the taskqueue implementation.
>
> This CR adds general documentation, and more importantly, references to
> papers about the implementation.
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8022784/webrev/
>
> Bugs.sun.com:
> http://http://bugs.sun.com/view_bug.do?bug_id=8022784
>
> JIRA:
> https://jbs.oracle.com/bugs/browse/JDK-8022784
>
> Testing:
> N/A
>
> Hth,
> Thomas
>

From christian.tornqvist at oracle.com  Mon Aug 12 05:51:18 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 12 Aug 2013 08:51:18 -0400
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <5208790D.9010309@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
Message-ID: <00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>

Hi Yumin,

The idea is to do as little as possible in the VM error handler, since we've crashed for some reason we don't know what state the process is in and we have to be extremely careful in when we're gathering the information. This seems like a step that is risky for all of the reasons David mentioned below.

It's also information that can easily be extracted post-mortem from the core/mdmp using the method you described for OSX, so gathering this at the time of a crash seems like an unnecessary risk.

Thanks,
Christian

-----Original Message-----
From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
Sent: Monday, August 12, 2013 1:56 AM
To: Yumin Qi
Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR: 8020962: dump loaded java classes when vm crash

Hi Yumin,

Note that the SA is only present in a full JDK, not a JRE (full or compact profile).

I have quite a few concerns with this:

We already do a lot of things that are not valid to be done from a signal handling context but this really takes that to an extreme. Doing fork-exec from a signal handler seems like a recipe for disaster (Note the existing onError facility is typically used for synchronous failures.)

The idea of launching a second VM to try and query a VM that has crashed also seems somewhat problematic:
- What mechanism will the SA try to use to query the VM?
- What if the state of the crashed VM stops the SA from being able to attach properly (ie both processes hang)?
- What if it the SA also crashes, will it launch a third VM then a fourth etc?

Also what is the nature of this dump? How big is it? Where will it go?

Thanks,
David

On 12/08/2013 9:36 AM, Yumin Qi wrote:
> Hi, all
>
>    I would like to have your review for
>
> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>
> Description: When JVM crashed, we also want to check the application 
> class files especially we got core file from customers.  The aftermath 
> analysis will benefit from all loaded java classes available. In this 
> change, spawn another process running SA to do the job when JVM 
> crashes, this way also avoid further messing up with the error report 
> which already in signal handler.
>
> Note: The test has done with following two bugs worked around:
>    8022655: ClassDump ignored jarStream setting (This will be fixed 
> and integrated by Kevin Walls soon)
>    8011888: sa.js: TypeError: [object JSAdapter] has no such function 
> "__has__" (Not know when it will be integrated)
>    That is, without those two fixed, the jars of loaded classes will 
> not be successfully dumped.
>    Also, on MacOS it requires security access permission to attach to 
> another process, so omit doing so. To get loaded jar file s, with core 
> file available (on all platforms), one can (only after this
> change) do
>
>    $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar 
> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>
>
> Thanks
> Yumin


From yumin.qi at oracle.com  Mon Aug 12 08:00:12 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 12 Aug 2013 08:00:12 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <52081FF6.4040205@oracle.com>
References: <52081FF6.4040205@oracle.com>
Message-ID: <5208F87C.1020407@oracle.com>

Sorry forgot to include svc.

Yumin

On 8/11/2013 4:36 PM, Yumin Qi wrote:
> Hi, all
>
>   I would like to have your review for
>
> http://cr.openjdk.java.net/~minqi/8020962/webrev0/ 
> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>
> Description: When JVM crashed, we also want to check the application 
> class files especially we got core file from customers.  The aftermath 
> analysis will benefit from all loaded java classes available. In this 
> change, spawn another process running SA to do the job when JVM 
> crashes, this way also avoid further messing up with the error report 
> which already in
> signal handler.
>
> Note: The test has done with following two bugs worked around:
>   8022655: ClassDump ignored jarStream setting (This will be fixed and 
> integrated by Kevin Walls soon)
>   8011888: sa.js: TypeError: [object JSAdapter] has no such function 
> "__has__" (Not know when it will be integrated)
>   That is, without those two fixed, the jars of loaded classes will 
> not be successfully dumped.
>   Also, on MacOS it requires security access permission to attach to 
> another process, so omit doing so. To get loaded jar file
> s, with core file available (on all platforms), one can (only after 
> this change) do
>
>   $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar 
> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>
>
> Thanks
> Yumin


From yumin.qi at oracle.com  Mon Aug 12 10:00:17 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 12 Aug 2013 10:00:17 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
Message-ID: <520914A1.8050905@oracle.com>

Chris, David

   Yes. This can be after crash with core file, but some time no core 
file generated (also if the error could not repeat, we will never got 
information again), so dumping  target process is also a choice. To 
avoid more confusion, this step was launched at the very last moment, 
just before raise abort to exit. At this moment, if client process could 
not attach to the target process it will exit right away.

Answers to David:

Note that the SA is only present in a full JDK, not a JRE (full or 
compact profile).
   Yes, in code, if no sa-jdi.jar found, skip fork.

- What mechanism will the SA try to use to query the VM?

   After successfully attached to target process, SA will read via proc 
APIs and vmStructs (named TYPEDB) to iterate  memory of system 
dictionary read (only)  from target process to dump class information.

- What if the state of the crashed VM stops the SA from being able to 
attach properly (ie both processes hang)?

   That should be an attaching API problem. We haven't watched such case 
happened so far.

- What if it the SA also crashes, will it launch a third VM then a 
fourth etc?

   Definitely don't want to see this happened in a chain. The solution 
may use a property such as 
sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into SA 
process, at launching call, check if the property set, if set, do not 
fork. When SA process died, it will generate core file first, note the 
target process still waiting for its exit, so when target exit, the core 
file (if both use default core as name) will be override by target. The 
SA process will only leave a hs_err_pid*.log file. (? read such property 
in handler is possible?)

  Also what is the nature of this dump? How big is it? Where will it go?
  The jars includes *app.jar and *boot.jar, the later usually can be 
ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent. 
The app.jar will contain all classes by customer, so we can do whatever 
we can to the jar.


Thanks
Yumin


On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
> Hi Yumin,
>
> The idea is to do as little as possible in the VM error handler, since we've crashed for some reason we don't know what state the process is in and we have to be extremely careful in when we're gathering the information. This seems like a step that is risky for all of the reasons David mentioned below.
>
> It's also information that can easily be extracted post-mortem from the core/mdmp using the method you described for OSX, so gathering this at the time of a crash seems like an unnecessary risk.
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
> Sent: Monday, August 12, 2013 1:56 AM
> To: Yumin Qi
> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>
> Hi Yumin,
>
> Note that the SA is only present in a full JDK, not a JRE (full or compact profile).
>
> I have quite a few concerns with this:
>
> We already do a lot of things that are not valid to be done from a signal handling context but this really takes that to an extreme. Doing fork-exec from a signal handler seems like a recipe for disaster (Note the existing onError facility is typically used for synchronous failures.)
>
> The idea of launching a second VM to try and query a VM that has crashed also seems somewhat problematic:
> - What mechanism will the SA try to use to query the VM?
> - What if the state of the crashed VM stops the SA from being able to attach properly (ie both processes hang)?
> - What if it the SA also crashes, will it launch a third VM then a fourth etc?
>
> Also what is the nature of this dump? How big is it? Where will it go?
>
> Thanks,
> David
>
> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>> Hi, all
>>
>>     I would like to have your review for
>>
>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>
>> Description: When JVM crashed, we also want to check the application
>> class files especially we got core file from customers.  The aftermath
>> analysis will benefit from all loaded java classes available. In this
>> change, spawn another process running SA to do the job when JVM
>> crashes, this way also avoid further messing up with the error report
>> which already in signal handler.
>>
>> Note: The test has done with following two bugs worked around:
>>     8022655: ClassDump ignored jarStream setting (This will be fixed
>> and integrated by Kevin Walls soon)
>>     8011888: sa.js: TypeError: [object JSAdapter] has no such function
>> "__has__" (Not know when it will be integrated)
>>     That is, without those two fixed, the jars of loaded classes will
>> not be successfully dumped.
>>     Also, on MacOS it requires security access permission to attach to
>> another process, so omit doing so. To get loaded jar file s, with core
>> file available (on all platforms), one can (only after this
>> change) do
>>
>>     $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>
>>
>> Thanks
>> Yumin


From ioi.lam at oracle.com  Mon Aug 12 11:00:54 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 12 Aug 2013 11:00:54 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <520914A1.8050905@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com>
Message-ID: <520922D6.6070107@oracle.com>

On 08/12/2013 10:00 AM, Yumin Qi wrote:
>
> - What if it the SA also crashes, will it launch a third VM then a 
> fourth etc?
>
>   Definitely don't want to see this happened in a chain. The solution 
> may use a property such as 
> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into 
> SA process, at launching call, check if the property set, if set, do 
> not fork. When SA process died, it will generate core file first, note 
> the target process still waiting for its exit, so when target exit, 
> the core file (if both use default core as name) will be override by 
> target. The SA process will only leave a hs_err_pid*.log file. (? read 
> such property in handler is possible?)

There is still the chance that the VM may have crashed before the 
properties are initialized. Maybe use environment variables instead?

- Ioi

From ioi.lam at oracle.com  Mon Aug 12 11:09:21 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 12 Aug 2013 11:09:21 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <52055DAF.90707@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
Message-ID: <520924D1.3040800@oracle.com>

Looks good.

Since you're touching the class loader code, maybe you should run 
vm.parallel_class_loading.testlist as well.

Thanks
- Ioi

On 08/09/2013 02:22 PM, Jiangli Zhou wrote:
> Hi,
>
> Could anyone help me review this?
>
> Thanks,
> Jiangli
>
> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>> Hi,
>>
>> Please review following change for JDK-8021948 
>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>
>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>
>> Both InstanceKlass::_source_file_name and 
>> InstanceKlass::_generic_signature were pointers to Symbol. They are 
>> now indexes to constant pool entries. Both fields are now u2 type, 
>> and co-located with other non-pointer type fields for more efficient 
>> alignment on 64-bit machine. On 32-bit machine, the change saves 
>> 4bytes for each class.
>>
>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>> nsk.stress.testlist and nsk.jvmti.testlist.
>>
>> Thanks,
>> Jiangli
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130812/1196bd83/attachment-0001.html 

From yumin.qi at oracle.com  Mon Aug 12 11:10:14 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 12 Aug 2013 11:10:14 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <520922D6.6070107@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com> <520922D6.6070107@oracle.com>
Message-ID: <52092506.2070407@oracle.com>

Ioi,

   Thanks for the reminding, it is possible. I will use env instead.

Yumin

On 8/12/2013 11:00 AM, Ioi Lam wrote:
> On 08/12/2013 10:00 AM, Yumin Qi wrote:
>>
>> - What if it the SA also crashes, will it launch a third VM then a 
>> fourth etc?
>>
>>   Definitely don't want to see this happened in a chain. The solution 
>> may use a property such as 
>> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into 
>> SA process, at launching call, check if the property set, if set, do 
>> not fork. When SA process died, it will generate core file first, 
>> note the target process still waiting for its exit, so when target 
>> exit, the core file (if both use default core as name) will be 
>> override by target. The SA process will only leave a hs_err_pid*.log 
>> file. (? read such property in handler is possible?)
>
> There is still the chance that the VM may have crashed before the 
> properties are initialized. Maybe use environment variables instead?
>
> - Ioi


From vladimir.kozlov at oracle.com  Mon Aug 12 11:32:48 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 12 Aug 2013 11:32:48 -0700
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
Message-ID: <52092A50.6000501@oracle.com>

Harold,

Code changes looks good.

You have typos in CDSCompressedKPtrsError.java (should be -XX:+ not +XX:-)

   53           "-XX:-UseCompressedKlassPointers", "+XX:-UseCompressedOops",

   60           "+XX:-UseCompressedKlassPointers", "-XX:-UseCompressedOops",

run jtreg with new tests and verify output.

Thanks,
Vladimir

On 8/9/13 7:57 AM, Harold Seigel wrote:
> Hi,
>
> Please review this latest version of the bug fix for 8003424: http://cr.openjdk.java.net/~hseigel/bug_8003424.3/
>
>
> This new version includes the following changes:
>
> 1. macroAssembler_sparc.cpp
>
>     a. Merged two versions of reinit_heapbase() into one.
>
>     b. Improved decode_klass_not_null(src, dst) to not use G6 if shift == 0.
>
>
> 2. macroAssembler_x86.cpp
>
>     a. Merged two versions of reinit_heapbase() into one.
>
>     b. Improved encode_klass_not_null(src, dst) to not use R12.
>
>     c. Replaced leaq with addq in decode_klass_not_null(src, dst).
>
>
> 3. Improved variable names in heap.cpp.
>
>
> 4. metaspace.cpp
>
>     a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more understandable.
>
>     b. Moved set_narrow_klass_base_and_shift() near can_use_cds_with_metaspace_addr().
>
>     c. Changed unneeded conditional in initialize_class_space() into an assert.
>
>
> 5. arguments.cpp
>
>     a. Fixed problem with -Xshare:dump and disabled compression.
>
>     b. Moved UseCompressedKlassPointers code into new function: set_use_compressed_klass_ptrs().
>
>     c. Fixed bug 8005933 that turned off CDS for -server even if -Xshare:auto was explicitly specified.
>
>
> 6. Increased default value of ClassMetaspaceSize to 1*G in globals.hpp.
>
>
> 7. Fixed indentation issues in metaspace.cpp and other modules.
>
>
> Thanks, Harold
>
> ----- Original Message -----
> From: harold.seigel at oracle.com
> To: coleen.phillimore at oracle.com
> Cc: hotspot-runtime-dev at openjdk.java.net
> Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern
> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for CompressedOops
>
> The purpose of this assert is to verify that the two methods in the 'if' clause closed the map file and disabled
> UseSharedSpaces if they detected a problem when trying to use CDS.
>
>        if (mapinfo->initialize() && MetaspaceShared::map_shared_spaces(mapinfo)) {
>          FileMapInfo::set_current_info(mapinfo);
>        } else {
>          assert(!mapinfo->is_open() && !UseSharedSpaces,
>                 "archive file not closed or shared spaces not disabled.");
>        }
>
> ----- Original Message -----
> From: harold.seigel at oracle.com
> To: coleen.phillimore at oracle.com
> Cc: hotspot-runtime-dev at openjdk.java.net
> Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for CompressedOops
>
> This is a bug that Stefan Karlsson also discovered.  To fix it, I've changed the code to this:
>
>    if (DumpSharedSpaces) {
>      if (RequireSharedSpaces) {
>        warning("cannot dump shared archive while using shared archive");
>      }
>      UseSharedSpaces = false;
> #ifdef _LP64
>      if (!UseCompressedOops || !UseCompressedKlassPointers) {
>        vm_exit_during_initialization(
>          "Cannot dump shared archive when UseCompressedOops or UseCompressedKlassPointers is off.", NULL);
>      }
>
> Harold
>
>
> ----- Original Message -----
> From: coleen.phillimore at oracle.com
> To: hotspot-runtime-dev at openjdk.java.net
> Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for CompressedOops
>
>
> Yes, there should be a check for that too.  Now I'll really let Harold
> answer.
>
> Thanks,
> Coleen
>
> On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
>  > Coleen, Harold
>  >
>  > > The InstanceKlass has offsets to fields in the instance, and they
>  > depend
>  > > on both compressed oops and compressed klass pointers.   So both
>  > have to
>  > > be on for the offsets to be valid.
>  >
>  > So there is dependency on UseCompressedOops and
>  > UseCompressedKlassPointers flags during dump.
>  >
>  > Then why the check is done only for UseSharedSpaces and not for
>  > DumpSharedSpaces?:
>  >
>  >     if (DumpSharedSpaces) {
>  >       if (RequireSharedSpaces) {
>  >         warning("cannot dump shared archive while using shared archive");
>  >       }
>  >       UseSharedSpaces = false;
>  > + #ifdef _LP64
>  > +   } else {
>  > +     // UseCompressedOops and UseCompressedKlassPointers must be on
>  > for UseSharedSpaces.
>  > +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>  > +       no_shared_spaces();
>  > +     }
>  > + #endif
>  >     }
>  >
>  > Thanks,
>  > Vladimir
>  >
>  > On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>  >>
>  >> Hi Vladimir,
>  >>
>  >> I have a couple of answers and I'll let Harold answer the rest.
>  >>
>  >> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>  >>> On 8/7/13 8:34 AM, harold seigel wrote:
>  >>>> Hi Vladimir,
>  >>>>
>  >>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>  >>>>> Harold,
>  >>>>>
>  >>>>> Note, on SPARC set() could generate up to 8 instructions to load
>  >>>>> 64-bit constant into register. So I am not sure that it will be
>  >>>>> faster
>  >>>>> than load.
>  >>>> We thought it would be faster because it doesn't need to load anything
>  >>>> from memory.
>  >>>
>  >>> For good value (0x800000000) it should use only 2-3 instructions.
>  >>> I think you can keep using set().
>  >>>
>  >>>>>
>  >>>>> I can't find where in CDS you store information about compressed
>  >>>>> klass
>  >>>>> pointers and compressed oops parameters which were used during dump?
>  >>>>> How you verify that correct parameters/flags are ussed when such CDS
>  >>>>> is used later?
>  >>>> No compressed klass pointers nor compressed oops get written to the
>  >>>> archive.  So, the compressed klass pointers and compressed oops
>  >>>> parameters do not need to be recorded in the archive.
>  >>>
>  >>> So you are saying that all klass pointers (references to klasses) in
>  >>> metadata structures in metaspace are full.
>  >>
>  >> Yes, they are.  (methodOops weren't in the InstanceKlass::_methods array
>  >> with Permgen but they are uncompressed now).
>  >>
>  >>> And klass pointers are only compressed in java object headers (which
>  >>> are not part of CDS). Right?
>  >>
>  >> The InstanceKlass has offsets to fields in the instance, and they depend
>  >> on both compressed oops and compressed klass pointers.   So both have to
>  >> be on for the offsets to be valid.
>  >>
>  >> But the base and compressed values are not stored anywhere in the CDS
>  >> archive.
>  >>
>  >>> And you don't care about UseCompressedOops and
>  >>> UseCompressedKlassPointers flags settings when you dump it into
>  >>> archive. The only limit is:
>  >>>
>  >>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total
>  >>>
>  >>> Then I don't understand why you can't use/load CDS archive when coop
>  >>> or compklass are off:
>  >>>
>  >>> > If coop is turned off then CDS cannot be used.  CDS will only be
>  >>> > supported if both UseCompressedOops and UseCompressedKlassPointers
>  >>> are
>  >>> > TRUE.
>  >>>
>  >>> Also based on code in arguments.cpp it is allowed to specify
>  >>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command line:
>  >>>
>  >>> 1466     // Turn on UseCompressedKlassPointers too
>  >>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>  >>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>  >>> 1469     }
>  >>>
>  >>> Did you tested such combination?
>  >>
>  >> I should let Harold answer this but I believe this is what his test
>  >> does.  For CDS on 64 bit, both must be on.   We didn't want to create 4
>  >> different archives.   And it wouldn't make too much sense since CDS for
>  >> 64 bit is a footprint savings so why would you use it without
>  >> compressing oops and class pointers?  It's not a startup savings on
>  >> server because we turn off interpreter bytecode quickening.
>  >>
>  >> Coleen
>  >>
>  >>>
>  >>>>>
>  >>>>> set_narrow_klass_base_and_shift() and
>  >>>>> can_use_cds_with_metaspace_addr() have the same code for
>  >>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>  >>>>> can_use_cds_with_metaspace_addr() from
>  >>>>> set_narrow_klass_base_and_shift() ?
>  >>>> I could add new inlined methods that determine the higher_address and
>  >>>> lower_base when UseSharedSpaces is true and have them called from
>  >>>> set_narrow_klass_base_and_shift() and
>  >>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>  >>>
>  >>> I tried several approaches but your implementation is more clean. So I
>  >>> agree to keep what you have now.
>  >>>
>  >>>
>  >>> Also I found strange assert which should always fail (old code in
>  >>> global_initialize() in metaspace.cpp):
>  >>>
>  >>> 2959     if (UseSharedSpaces) {
>  >>> ...
>  >>> 2969       } else {
>  >>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>  >>> 2971                "archive file not closed or shared spaces not
>  >>> disabled.");
>  >>>
>  >>> Thanks,
>  >>> Vladimir
>  >>>
>  >>>>>
>  >>>>> I see that you unconditionally set comp klass ptr base and shift for
>  >>>>> DumpSharedSpaces. Should you do the check similar to
>  >>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>  >>>>> don't even check UseCompressedKlassPointers.
>  >>>> I don't think the checks are needed because the information written to
>  >>>> the archive is not affected by the size of the class metaspace.
>  >>>>
>  >>>> Also, I recently added code to arguments.cpp that will generate an
>  >>>> error
>  >>>> if UseCompressedOops or UseCompressedKlassPointers is turned off and
>  >>>> DumpSharedSpaces is on.
>  >>>>>
>  >>>>> Why you have next limitation? What if coop can't be used because of
>  >>>>> big heap?:
>  >>>>>
>  >>>>> +     // UseCompressedOops and UseCompressedKlassPointers must be on
>  >>>>> for UseSharedSpaces.
>  >>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>  >>>>> +       no_shared_spaces();
>  >>>> If coop is turned off then CDS cannot be used.  CDS will only be
>  >>>> supported if both UseCompressedOops and UseCompressedKlassPointers are
>  >>>> TRUE.
>  >>>>>
>  >>>>> Could you move UseCompressedKlassPointers code in arguments.cpp into
>  >>>>> separate method similar to set_use_compressed_oops()?
>  >>>> Done.
>  >>>>>
>  >>>>> About new tests.
>  >>>>> The first test in CDSCompressedKPtrsError misses
>  >>>>> -XX:+UseCompressedOops flag.
>  >>>> Fixed.
>  >>>>>
>  >>>>> Could you also test cross flags combinations?:
>  >>>>>
>  >>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>  >>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>  >>>> Done.
>  >>>>>
>  >>>>> It would be nice to have test to check ClassMetaspaceSize value
>  >>>>> range.
>  >>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint
>  >>>>> or maxuint.
>  >>>> A member of our runtime SQE group is writing additional tests. I'll
>  >>>> ask
>  >>>> him to write a ClassMetaspaceSize range test.
>  >>>>
>  >>>> We chose 3Gb because we thought it was a sufficiently large size.
>  >>>>>
>  >>>>>
>  >>>>> About code style, indention. We align next line to corresponding part
>  >>>>> of previous line if we need to split a line. And sometimes it is
>  >>>>> better to keep one long line. I understand some of them were before
>  >>>>> your changes but, please, clean up at lest ones you touched.
>  >>>> Done.
>  >>>>>
>  >>>>> Cases in metaspace.cpp:
>  >>>>>
>  >>>>> 2263   assert(raw_word_size >= min_size,
>  >>>>> 2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<"
>  >>>>> SIZE_FORMAT, word_size, min_size));
>  >>>>>
>  >>>>>
>  >>>>> 2485   if (Metaspace::using_class_space() &&
>  >>>>> 2486     (Metaspace::class_space_list() != NULL)) {
>  >>>>>
>  >>>>>
>  >>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>  >>>>> 2575                       (Metaspace::using_class_space() ?
>  >>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>  >>>>> 2577 Metaspace::space_list()->virtual_space_total();
>  >>>>>
>  >>>>>
>  >>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>  >>>>> SIZE_FORMAT ", "
>  >>>>> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT
>  >>>>> ", "
>  >>>>> 2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT
>  >>>>> ", "
>  >>>>> 2697                            "large count " SIZE_FORMAT,
>  >>>>> 2698              cls_specialized_count, cls_specialized_waste,
>  >>>>> 2699              cls_small_count, cls_small_waste,
>  >>>>> 2700              cls_medium_count, cls_medium_waste,
>  >>>>> cls_humongous_count);
>  >>>>>
>  >>>>>
>  >>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G >
>  >>>>> addr) &&
>  >>>>> 2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>  >>>>>
>  >>>>>
>  >>>>> 2889         vm_exit_during_initialization(err_msg(
>  >>>>> 2890           "Could not allocate metaspace: %d bytes",
>  >>>>> 2891           class_metaspace_size()));
>  >>>>>
>  >>>>>
>  >>>>> 3107     return using_class_space() ?
>  >>>>> 3108       class_vsm()->sum_used_in_chunks_in_use() : 0;
>  >>>>>
>  >>>>>
>  >>>>> 3157     if (is_class && using_class_space()) {
>  >>>>> 3158        class_vsm()->deallocate(ptr, word_size);
>  >>>>>
>  >>>>>
>  >>>>> 3305   return space_list()->contains(ptr) ||
>  >>>>> 3306     (using_class_space() && class_space_list()->contains(ptr));
>  >>>>>
>  >>>>> metaspace.hpp:
>  >>>>>
>  >>>>>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
>  >>>>>  271       (Metaspace::using_class_space() ?
>  >>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>  >>>>>
>  >>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>  >>>>>  286       (Metaspace::using_class_space() ?
>  >>>>>  287         _allocated_used_words[Metaspace::ClassType] : 0);
>  >>>>>
>  >>>>> universe.cpp:
>  >>>>>
>  >>>>>  849   assert((intptr_t)Universe::narrow_oop_base() <=
>  >>>>> (intptr_t)(Universe::heap()->base() -
>  >>>>>  850     os::vm_page_size()) ||
>  >>>>>  851            Universe::narrow_oop_base() == NULL, "invalid
>  >>>>> value");
>  >>>>>
>  >>>>>
>  >>>>> Thanks,
>  >>>>> Vladimir
>  >>>>>
>  >>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>  >>>>>> Hi,
>  >>>>>>
>  >>>>>> Please review this updated webrev for bug 8003424:
>  >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>  >>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>  >>>>>>
>  >>>>>> The updated webrev has a lot of changes from the previous webrev,
>  >>>>>> including the following:
>  >>>>>>
>  >>>>>>     1. Class metaspace information is now output when
>  >>>>>>     -XX:+PrintCompressedOopsMode is specified.
>  >>>>>>
>  >>>>>>     2. decode_klass_not_null(Register dst, Register src) no longer
>  >>>>>>     clobbers R12.
>  >>>>>>
>  >>>>>>     3. Method using_class_vsm() was renamed to using_class_space().
>  >>>>>>
>  >>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>  >>>>>> appropriate.
>  >>>>>>
>  >>>>>>     5. The Metaspace:: qualifier was removed, where it was
>  >>>>>> unnecessary.
>  >>>>>>
>  >>>>>>     6. Metaspace::initialize_class_space() was made private.
>  >>>>>>
>  >>>>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>  >>>>>> updated.
>  >>>>>>
>  >>>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005,
>  >>>>>> and
>  >>>>>> specjbb2013.  The results showed no significant performance
>  >>>>>> difference
>  >>>>>> in terms of scores and gc behavior.
>  >>>>>>
>  >>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>  >>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>  >>>>>>
>  >>>>>> Please let me know what additional tests should be run.
>  >>>>>>
>  >>>>>> Thanks!
>  >>>>>> Harold
>  >>>>>>
>  >>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>  >>>>>>> Hi Harold,
>  >>>>>>>
>  >>>>>>> > Usually the narrow_klass_base will be 32G and the
>  >>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which
>  >>>>>>> means
>  >>>>>>> that
>  >>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>  >>>>>>> unless
>  >>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that
>  >>>>>>> make
>  >>>>>>> sense?
>  >>>>>>>
>  >>>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000
>  >>>>>>> and I
>  >>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>  >>>>>>> (assuming or
>  >>>>>>> with check that class metaspace size < 32Gb).
>  >>>>>>>
>  >>>>>>> > Is there one prefix byte per instruction, or just for certain
>  >>>>>>> instructions?
>  >>>>>>>
>  >>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>  >>>>>>> prefix is
>  >>>>>>> necessary only if an instruction references one of the extended
>  >>>>>>> registers or uses a 64-bit operand."
>  >>>>>>>
>  >>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and
>  >>>>>>> =32
>  >>>>>>> and big java heap. Recently we got several bugs which indicated
>  >>>>>>> that
>  >>>>>>> we did not separate cleanly oops and klass pointers en/decoding.
>  >>>>>>>
>  >>>>>>> Thanks,
>  >>>>>>> Vladimir
>  >>>>>>>
>  >>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>  >>>>>>>> Hi Vladimir,
>  >>>>>>>>
>  >>>>>>>> Thank you for the review!  Please see inline comments.
>  >>>>>>>>
>  >>>>>>>> Thanks, Harold
>  >>>>>>>>
>  >>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>  >>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>  >>>>>>>>>> Nice clean up, Harold
>  >>>>>>>>>>
>  >>>>>>>>>> Could you add the size of class metaspace in output with
>  >>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>  >>>>>>>>>> remember an
>  >>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>  >>>>>>>> Will be done in next webrev.
>  >>>>>>>>>>
>  >>>>>>>>>> Also it would be nice to print these info line (and compressed
>  >>>>>>>>>> oops
>  >>>>>>>>>> info
>  >>>>>>>>>> line) in hs_err files.
>  >>>>>>>> I filed an enhancement bug for this: 8021264
>  >>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>  >>>>>>>>>>
>  >>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>  >>>>>>>>>> x86_64.ad.
>  >>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use
>  >>>>>>>>>> arithmetic
>  >>>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also
>  >>>>>>>>>> note
>  >>>>>>>>>> that code in .ad file does not check the encoding mode for
>  >>>>>>>>>> narrow
>  >>>>>>>>>> klass/oop so it should be conservative and assume that
>  >>>>>>>>>> arithmetic
>  >>>>>>>>>> instructions are used.
>  >>>>>>>> OK. Thanks.
>  >>>>>>>>>>
>  >>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>  >>>>>>>>>> 4Gb so
>  >>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>  >>>>>>>>>> encoding/decoding without destroying R12.
>  >>>>>>>>>
>  >>>>>>>>> Correction. You can do it only if base < 2Gb max positive int
>  >>>>>>>>> (sign
>  >>>>>>>>> bit is extended so you will get wrong result with address > 2gb).
>  >>>>>>>> But the base will normally be 32Gb.  So this case won't happen
>  >>>>>>>> very
>  >>>>>>>> often.
>  >>>>>>>>>
>  >>>>>>>>> You definitely should not use R12 in
>  >>>>>>>>> decode_klass_not_null(Register
>  >>>>>>>>> dst, Register src) method where you have free 'dst' register.
>  >>>>>>>> Will be fixed in next webrev.
>  >>>>>>>>>
>  >>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>  >>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be
>  >>>>>>>>> 64Gb.
>  >>>>>>>>> The idea was to avoid using R12 by using shifted base:
>  >>>>>>>>>
>  >>>>>>>>> decode:
>  >>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>  >>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>  >>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>  >>>>>>>>>   }
>  >>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>  >>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>  >>>>>>>>> }
>  >>>>>>>>>
>  >>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>  >>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <=
>  >>>>>>>>> maxint
>  >>>>>>>>> (max positive int).
>  >>>>>>>> Usually the narrow_klass_base will be 32G and the
>  >>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>  >>>>>>>> that
>  >>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>  >>>>>>>> unless
>  >>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that
>  >>>>>>>> make
>  >>>>>>>> sense?
>  >>>>>>>>>
>  >>>>>>>>> And you have general memory reservation problem. At least on
>  >>>>>>>>> Solaris,
>  >>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
>  >>>>>>>>> between
>  >>>>>>>>> different requested memory regions. That is why in jdk7 we first
>  >>>>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>  >>>>>>>>> protection page below heap to catch implicit NULL exceptions with
>  >>>>>>>>> compressed oops.
>  >>>>>>>>>
>  >>>>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>  >>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>  >>>>>>>>> compressed
>  >>>>>>>>> oops and with Xmx20Gb.
>  >>>>>>>> I verifed that we get either cds_address+cds_total as the
>  >>>>>>>> address, or
>  >>>>>>>> CompressedKlassPointersBase as the address without CDS on Linux,
>  >>>>>>>> Windows
>  >>>>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap
>  >>>>>>>> sizes and
>  >>>>>>>> -Xmx32G.
>  >>>>>>>>
>  >>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the
>  >>>>>>>> desired
>  >>>>>>>> CDS address for class metaspace regardless of heap size.
>  >>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>  >>>>>>>>>> unfortunately we
>  >>>>>>>>>> can't do other way. I assume you use max size because
>  >>>>>>>>>> depending on
>  >>>>>>>>>> registers used in instructions you will or will not get prefix
>  >>>>>>>>>> byte
>  >>>>>>>>>> (r8-r15).
>  >>>>>>>> Is there one prefix byte per instruction, or just for certain
>  >>>>>>>> instructions?
>  >>>>>>>>>>
>  >>>>>>>>>> I will look on changes in more details may be late.
>  >>>>>>>>>
>  >>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use
>  >>>>>>>>> abbreviations
>  >>>>>>>>> which are not obvious.
>  >>>>>>>> I changed using_class_vsm() to using_class_space().
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>> Thanks,
>  >>>>>>>>>> Vladimir
>  >>>>>>>>>>
>  >>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>  >>>>>>>>>>> Hi,
>  >>>>>>>>>>>
>  >>>>>>>>>>> Please review this fix for bug 8003424.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>  >>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>  >>>>>>>>>>> Open bug links at:
>  >>>>>>>>>>>
>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>  >>>>>>>>>>>
>  >>>>>>>>>>> JBS Bug links at
>  >>>>>>>>>>>
>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>> This fix provides support for using compressed klass pointers
>  >>>>>>>>>>> with
>  >>>>>>>>>>> CDS.
>  >>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>  >>>>>>>>>>> platforms
>  >>>>>>>>>>> when
>  >>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the
>  >>>>>>>>>>> class
>  >>>>>>>>>>> metaspace as part of the Java Heap allocation and locating
>  >>>>>>>>>>> it at
>  >>>>>>>>>>> the
>  >>>>>>>>>>> base of that allocation, the metaspace will now be allocated
>  >>>>>>>>>>> separately,
>  >>>>>>>>>>> above the Java heap.  This will enable future expansion of the
>  >>>>>>>>>>> metaspace
>  >>>>>>>>>>> because it won't be backed up against the Java heap. If CDS is
>  >>>>>>>>>>> being
>  >>>>>>>>>>> used, then the CDS region will be allocated between the Java
>  >>>>>>>>>>> heap and
>  >>>>>>>>>>> the metaspace.
>  >>>>>>>>>>>
>  >>>>>>>>>>> The new class metaspace allocation code tries to allocate
>  >>>>>>>>>>> memory at
>  >>>>>>>>>>> 32G,
>  >>>>>>>>>>> or above the CDS region, if it is present. Because of this,
>  >>>>>>>>>>> encoding
>  >>>>>>>>>>> and decoding of compressed klass pointers will always
>  >>>>>>>>>>> require use
>  >>>>>>>>>>> of a
>  >>>>>>>>>>> base register.  So, encoding and decoding of compressed klass
>  >>>>>>>>>>> pointers
>  >>>>>>>>>>> will differ from compressed oops.
>  >>>>>>>>>>>
>  >>>>>>>>>>> There are no class metaspace allocation changes if
>  >>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
>  >>>>>>>>>>> 32-bit
>  >>>>>>>>>>> platform.
>  >>>>>>>>>>>
>  >>>>>>>>>>> The code changes also include some cleanup and will fix bugs
>  >>>>>>>>>>> 8016729,
>  >>>>>>>>>>> 8011610, and 8003424.
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>> Many of the modules in this webrev contain a lot of changes.
>  >>>>>>>>>>> Modules
>  >>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>  >>>>>>>>>>> changed to
>  >>>>>>>>>>> support the new encoding and decoding of compressed klass
>  >>>>>>>>>>> pointers.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Module metaspace.cpp was changed significantly to support
>  >>>>>>>>>>> the new
>  >>>>>>>>>>> allocation for metaspace and the CDS region and to determine
>  >>>>>>>>>>> compressed
>  >>>>>>>>>>> klass pointer encoding base and shifting values.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Most of the changes to module universe.cpp were to remove code
>  >>>>>>>>>>> related
>  >>>>>>>>>>> to allocating metaspace and remove code that considered
>  >>>>>>>>>>> compressed
>  >>>>>>>>>>> klass
>  >>>>>>>>>>> pointers when determining the compressed oops compression
>  >>>>>>>>>>> mechanism.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as
>  >>>>>>>>>>> part
>  >>>>>>>>>>> of a
>  >>>>>>>>>>> cleanup requested by Coleen.
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
>  >>>>>>>>>>> tests,
>  >>>>>>>>>>> JPRT,
>  >>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and
>  >>>>>>>>>>> vm.mlvm.testlist
>  >>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and
>  >>>>>>>>>>> -Xshare:off
>  >>>>>>>>>>> (with
>  >>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit
>  >>>>>>>>>>> Linux and
>  >>>>>>>>>>> 64-Bit
>  >>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests
>  >>>>>>>>>>> were
>  >>>>>>>>>>> run on Solaris x86.
>  >>>>>>>>>>>
>  >>>>>>>>>>> The performance impact of these changes is TBD.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Thanks, Harold
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>
>  >>>>>>
>  >>>>
>  >>
>

From jiangli.zhou at oracle.com  Mon Aug 12 13:45:36 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Mon, 12 Aug 2013 13:45:36 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <520924D1.3040800@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com>
Message-ID: <52094970.1030206@oracle.com>

Hi Ioi,

Thanks for the review! I'll try those tests also.

Thanks,
Jiangli

On 08/12/2013 11:09 AM, Ioi Lam wrote:
> Looks good.
>
> Since you're touching the class loader code, maybe you should run 
> vm.parallel_class_loading.testlist as well.
>
> Thanks
> - Ioi
>
> On 08/09/2013 02:22 PM, Jiangli Zhou wrote:
>> Hi,
>>
>> Could anyone help me review this?
>>
>> Thanks,
>> Jiangli
>>
>> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>>> Hi,
>>>
>>> Please review following change for JDK-8021948 
>>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>>
>>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>>
>>> Both InstanceKlass::_source_file_name and 
>>> InstanceKlass::_generic_signature were pointers to Symbol. They are 
>>> now indexes to constant pool entries. Both fields are now u2 type, 
>>> and co-located with other non-pointer type fields for more efficient 
>>> alignment on 64-bit machine. On 32-bit machine, the change saves 
>>> 4bytes for each class.
>>>
>>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>>> nsk.stress.testlist and nsk.jvmti.testlist.
>>>
>>> Thanks,
>>> Jiangli
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130812/bae86fe6/attachment.html 

From daniel.daugherty at oracle.com  Mon Aug 12 14:14:20 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 12 Aug 2013 15:14:20 -0600
Subject: RFR 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
In-Reply-To: <52016BBB.3040907@oracle.com>
References: <52016BBB.3040907@oracle.com>
Message-ID: <5209502C.7040709@oracle.com>

On 8/6/13 3:33 PM, Coleen Phillimore wrote:
> Summary: ActiveMethodOopsCache was used to keep track of old versions 
> of some methods that are cached in Universe but is buggy with permgen 
> removal and not needed anymore
>
> There was a crash in this function that I couldn't reproduce.  It was 
> likely that the crash was for something else, but this is a lurking bug.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8009728/

Thumbs up!

src/share/vm/memory/universe.cpp
     No comments.

src/share/vm/memory/universe.hpp
     nit lines 59-63: if you wanted to make the the function names all
         line up that would look better

src/share/vm/oops/method.cpp
     No comments.

src/share/vm/prims/jvmtiRedefineClasses.cpp
     No comments.

test/runtime/RedefineObject/Agent.java
     I like the refactor of the redefine logic into the redefine() method
     and that makes the premain() method more clear.

test/runtime/RedefineObject/TestRedefineObject.java
     No comments.

test/runtime/RedefineObject/WalkThroughInvoke.java
     line 30: // walks the stack before it gets this exception.
         Is the "this exception" mentioned here this one:

         line 33: } catch (java.security.AccessControlException e) {

     line 34: System.out.println("This exception is expected");
         This println() is in the catch of AccessControlException
         so there won't be any mention of that exception in the test's
         output, but the test's output will say:

             This exception is expected

         This could be confusing to anyone that is investigating
         and/or looking at this test. You might say:

             Ignoring an 'AccessControlException' exception since
             it is expected as part of this test.

Dan


> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009728
> local bug link https://jbs.oracle.com/bugs/browse/JDK-8009728
>
> Tested with vm.quick.testlist which includes redefine classes tests 
> and jck lang and vm tests.
>
> Thanks,
> Coleen
>


From coleen.phillimore at oracle.com  Mon Aug 12 14:17:24 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 12 Aug 2013 17:17:24 -0400
Subject: RFR 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
In-Reply-To: <5209502C.7040709@oracle.com>
References: <52016BBB.3040907@oracle.com> <5209502C.7040709@oracle.com>
Message-ID: <520950E4.7060808@oracle.com>


Thanks Dan for reviewing this version of this change also.  See inline 
comments.

On 08/12/2013 05:14 PM, Daniel D. Daugherty wrote:
> On 8/6/13 3:33 PM, Coleen Phillimore wrote:
>> Summary: ActiveMethodOopsCache was used to keep track of old versions 
>> of some methods that are cached in Universe but is buggy with permgen 
>> removal and not needed anymore
>>
>> There was a crash in this function that I couldn't reproduce. It was 
>> likely that the crash was for something else, but this is a lurking bug.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8009728/
>
> Thumbs up!
>
> src/share/vm/memory/universe.cpp
>     No comments.
>
> src/share/vm/memory/universe.hpp
>     nit lines 59-63: if you wanted to make the the function names all
>         line up that would look better

done.

>
> src/share/vm/oops/method.cpp
>     No comments.
>
> src/share/vm/prims/jvmtiRedefineClasses.cpp
>     No comments.
>
> test/runtime/RedefineObject/Agent.java
>     I like the refactor of the redefine logic into the redefine() method
>     and that makes the premain() method more clear.
>
> test/runtime/RedefineObject/TestRedefineObject.java
>     No comments.
>
> test/runtime/RedefineObject/WalkThroughInvoke.java
>     line 30: // walks the stack before it gets this exception.
>         Is the "this exception" mentioned here this one:
>
>         line 33: } catch (java.security.AccessControlException e) {
>
>     line 34: System.out.println("This exception is expected");
>         This println() is in the catch of AccessControlException
>         so there won't be any mention of that exception in the test's
>         output, but the test's output will say:
>
>             This exception is expected
>
>         This could be confusing to anyone that is investigating
>         and/or looking at this test. You might say:
>
>             Ignoring an 'AccessControlException' exception since
>             it is expected as part of this test.
>

I added your comment and fixed the comments so hopefully they make sense.

public class WalkThroughInvoke {
   public void stackWalk() {
       try {
           Class b = Object.class;
           SecurityManager sm = new SecurityManager();
           // walks the stack with Method.invoke in the stack (which is the
           // purpose of the test) before it gets an AccessControlException.
           sm.checkMemberAccess(b, Member.DECLARED);
       } catch (java.security.AccessControlException e) {
           // Ignoring an 'AccessControlException' exception since
           //  it is expected as part of this test.
       }
   }
};


Thanks!
Coleen

> Dan
>
>
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009728
>> local bug link https://jbs.oracle.com/bugs/browse/JDK-8009728
>>
>> Tested with vm.quick.testlist which includes redefine classes tests 
>> and jck lang and vm tests.
>>
>> Thanks,
>> Coleen
>>
>


From coleen.phillimore at oracle.com  Mon Aug 12 14:43:46 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 12 Aug 2013 17:43:46 -0400
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <520914A1.8050905@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com>
Message-ID: <52095712.4080404@oracle.com>


Yumin,

I don't think this change should be added to the JVM for the following 
reasons.

1. Error handling should only contain safe actions.   We have concerns 
that the SA is not that stable and would prevent getting a real core 
file in many error situations.   You couldn't have tested all error 
situations because these are usually the things we don't know about.   
You also mention that there are currently bugs preventing this feature 
from working in your first email.

2. I am not convinced that having a separate jar file with loaded 
classes (is it a list that SA generates?) would be collected by an error 
reporter.   If it's collected, I don't see how helpful it would be.  
Also a customer may not want their classes disclosed in error reporting.

3.  This doesn't seem important enough to include as a new feature in 
jdk8 release, which is feature-complete.   I don't see a customer 
request for it.

Coleen

On 08/12/2013 01:00 PM, Yumin Qi wrote:
> Chris, David
>
>   Yes. This can be after crash with core file, but some time no core 
> file generated (also if the error could not repeat, we will never got 
> information again), so dumping  target process is also a choice. To 
> avoid more confusion, this step was launched at the very last moment, 
> just before raise abort to exit. At this moment, if client process 
> could not attach to the target process it will exit right away.
>
> Answers to David:
>
> Note that the SA is only present in a full JDK, not a JRE (full or 
> compact profile).
>   Yes, in code, if no sa-jdi.jar found, skip fork.
>
> - What mechanism will the SA try to use to query the VM?
>
>   After successfully attached to target process, SA will read via proc 
> APIs and vmStructs (named TYPEDB) to iterate  memory of system 
> dictionary read (only)  from target process to dump class information.
>
> - What if the state of the crashed VM stops the SA from being able to 
> attach properly (ie both processes hang)?
>
>   That should be an attaching API problem. We haven't watched such 
> case happened so far.
>
> - What if it the SA also crashes, will it launch a third VM then a 
> fourth etc?
>
>   Definitely don't want to see this happened in a chain. The solution 
> may use a property such as 
> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into 
> SA process, at launching call, check if the property set, if set, do 
> not fork. When SA process died, it will generate core file first, note 
> the target process still waiting for its exit, so when target exit, 
> the core file (if both use default core as name) will be override by 
> target. The SA process will only leave a hs_err_pid*.log file. (? read 
> such property in handler is possible?)
>
>  Also what is the nature of this dump? How big is it? Where will it go?
>  The jars includes *app.jar and *boot.jar, the later usually can be 
> ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent. 
> The app.jar will contain all classes by customer, so we can do 
> whatever we can to the jar.
>
>
> Thanks
> Yumin
>
>
> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>> Hi Yumin,
>>
>> The idea is to do as little as possible in the VM error handler, 
>> since we've crashed for some reason we don't know what state the 
>> process is in and we have to be extremely careful in when we're 
>> gathering the information. This seems like a step that is risky for 
>> all of the reasons David mentioned below.
>>
>> It's also information that can easily be extracted post-mortem from 
>> the core/mdmp using the method you described for OSX, so gathering 
>> this at the time of a crash seems like an unnecessary risk.
>>
>> Thanks,
>> Christian
>>
>> -----Original Message-----
>> From: hotspot-compiler-dev-bounces at openjdk.java.net 
>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of 
>> David Holmes
>> Sent: Monday, August 12, 2013 1:56 AM
>> To: Yumin Qi
>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>
>> Hi Yumin,
>>
>> Note that the SA is only present in a full JDK, not a JRE (full or 
>> compact profile).
>>
>> I have quite a few concerns with this:
>>
>> We already do a lot of things that are not valid to be done from a 
>> signal handling context but this really takes that to an extreme. 
>> Doing fork-exec from a signal handler seems like a recipe for 
>> disaster (Note the existing onError facility is typically used for 
>> synchronous failures.)
>>
>> The idea of launching a second VM to try and query a VM that has 
>> crashed also seems somewhat problematic:
>> - What mechanism will the SA try to use to query the VM?
>> - What if the state of the crashed VM stops the SA from being able to 
>> attach properly (ie both processes hang)?
>> - What if it the SA also crashes, will it launch a third VM then a 
>> fourth etc?
>>
>> Also what is the nature of this dump? How big is it? Where will it go?
>>
>> Thanks,
>> David
>>
>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>     I would like to have your review for
>>>
>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>
>>> Description: When JVM crashed, we also want to check the application
>>> class files especially we got core file from customers.  The aftermath
>>> analysis will benefit from all loaded java classes available. In this
>>> change, spawn another process running SA to do the job when JVM
>>> crashes, this way also avoid further messing up with the error report
>>> which already in signal handler.
>>>
>>> Note: The test has done with following two bugs worked around:
>>>     8022655: ClassDump ignored jarStream setting (This will be fixed
>>> and integrated by Kevin Walls soon)
>>>     8011888: sa.js: TypeError: [object JSAdapter] has no such function
>>> "__has__" (Not know when it will be integrated)
>>>     That is, without those two fixed, the jars of loaded classes will
>>> not be successfully dumped.
>>>     Also, on MacOS it requires security access permission to attach to
>>> another process, so omit doing so. To get loaded jar file s, with core
>>> file available (on all platforms), one can (only after this
>>> change) do
>>>
>>>     $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>
>>>
>>> Thanks
>>> Yumin
>


From christian.tornqvist at oracle.com  Mon Aug 12 15:50:29 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 12 Aug 2013 18:50:29 -0400
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <52095712.4080404@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com> <52095712.4080404@oracle.com>
Message-ID: <008b01ce97ae$583efdf0$08bcf9d0$@oracle.com>

I agree with Coleen, this change should not be added to the JVM. 

Though I'd like to have the tool to create this archive from a core/mdmp. If this is not already present in any of the j*-tools we might want to look into adding it, please work with the serviceability team to determine where this would be best suited.

Thanks,
Christian

-----Original Message-----
From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] 
Sent: Monday, August 12, 2013 5:44 PM
To: Yumin Qi
Cc: Christian Tornqvist; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; 'hotspot compiler'; 'David Holmes'; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR: 8020962: dump loaded java classes when vm crash


Yumin,

I don't think this change should be added to the JVM for the following reasons.

1. Error handling should only contain safe actions.   We have concerns 
that the SA is not that stable and would prevent getting a real core 
file in many error situations.   You couldn't have tested all error 
situations because these are usually the things we don't know about.   
You also mention that there are currently bugs preventing this feature from working in your first email.

2. I am not convinced that having a separate jar file with loaded classes (is it a list that SA generates?) would be collected by an error 
reporter.   If it's collected, I don't see how helpful it would be.  
Also a customer may not want their classes disclosed in error reporting.

3.  This doesn't seem important enough to include as a new feature in 
jdk8 release, which is feature-complete.   I don't see a customer 
request for it.

Coleen

On 08/12/2013 01:00 PM, Yumin Qi wrote:
> Chris, David
>
>   Yes. This can be after crash with core file, but some time no core 
> file generated (also if the error could not repeat, we will never got 
> information again), so dumping  target process is also a choice. To 
> avoid more confusion, this step was launched at the very last moment, 
> just before raise abort to exit. At this moment, if client process 
> could not attach to the target process it will exit right away.
>
> Answers to David:
>
> Note that the SA is only present in a full JDK, not a JRE (full or 
> compact profile).
>   Yes, in code, if no sa-jdi.jar found, skip fork.
>
> - What mechanism will the SA try to use to query the VM?
>
>   After successfully attached to target process, SA will read via proc 
> APIs and vmStructs (named TYPEDB) to iterate  memory of system 
> dictionary read (only)  from target process to dump class information.
>
> - What if the state of the crashed VM stops the SA from being able to 
> attach properly (ie both processes hang)?
>
>   That should be an attaching API problem. We haven't watched such 
> case happened so far.
>
> - What if it the SA also crashes, will it launch a third VM then a 
> fourth etc?
>
>   Definitely don't want to see this happened in a chain. The solution 
> may use a property such as 
> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into 
> SA process, at launching call, check if the property set, if set, do 
> not fork. When SA process died, it will generate core file first, note 
> the target process still waiting for its exit, so when target exit, 
> the core file (if both use default core as name) will be override by 
> target. The SA process will only leave a hs_err_pid*.log file. (? read 
> such property in handler is possible?)
>
>  Also what is the nature of this dump? How big is it? Where will it go?
>  The jars includes *app.jar and *boot.jar, the later usually can be 
> ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent.
> The app.jar will contain all classes by customer, so we can do 
> whatever we can to the jar.
>
>
> Thanks
> Yumin
>
>
> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>> Hi Yumin,
>>
>> The idea is to do as little as possible in the VM error handler, 
>> since we've crashed for some reason we don't know what state the 
>> process is in and we have to be extremely careful in when we're 
>> gathering the information. This seems like a step that is risky for 
>> all of the reasons David mentioned below.
>>
>> It's also information that can easily be extracted post-mortem from 
>> the core/mdmp using the method you described for OSX, so gathering 
>> this at the time of a crash seems like an unnecessary risk.
>>
>> Thanks,
>> Christian
>>
>> -----Original Message-----
>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of 
>> David Holmes
>> Sent: Monday, August 12, 2013 1:56 AM
>> To: Yumin Qi
>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>
>> Hi Yumin,
>>
>> Note that the SA is only present in a full JDK, not a JRE (full or 
>> compact profile).
>>
>> I have quite a few concerns with this:
>>
>> We already do a lot of things that are not valid to be done from a 
>> signal handling context but this really takes that to an extreme.
>> Doing fork-exec from a signal handler seems like a recipe for 
>> disaster (Note the existing onError facility is typically used for 
>> synchronous failures.)
>>
>> The idea of launching a second VM to try and query a VM that has 
>> crashed also seems somewhat problematic:
>> - What mechanism will the SA try to use to query the VM?
>> - What if the state of the crashed VM stops the SA from being able to 
>> attach properly (ie both processes hang)?
>> - What if it the SA also crashes, will it launch a third VM then a 
>> fourth etc?
>>
>> Also what is the nature of this dump? How big is it? Where will it go?
>>
>> Thanks,
>> David
>>
>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>     I would like to have your review for
>>>
>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>
>>> Description: When JVM crashed, we also want to check the application 
>>> class files especially we got core file from customers.  The 
>>> aftermath analysis will benefit from all loaded java classes 
>>> available. In this change, spawn another process running SA to do 
>>> the job when JVM crashes, this way also avoid further messing up 
>>> with the error report which already in signal handler.
>>>
>>> Note: The test has done with following two bugs worked around:
>>>     8022655: ClassDump ignored jarStream setting (This will be fixed 
>>> and integrated by Kevin Walls soon)
>>>     8011888: sa.js: TypeError: [object JSAdapter] has no such 
>>> function "__has__" (Not know when it will be integrated)
>>>     That is, without those two fixed, the jars of loaded classes 
>>> will not be successfully dumped.
>>>     Also, on MacOS it requires security access permission to attach 
>>> to another process, so omit doing so. To get loaded jar file s, with 
>>> core file available (on all platforms), one can (only after this
>>> change) do
>>>
>>>     $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar 
>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>
>>>
>>> Thanks
>>> Yumin
>



From ioi.lam at oracle.com  Mon Aug 12 16:14:32 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 12 Aug 2013 16:14:32 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <008b01ce97ae$583efdf0$08bcf9d0$@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com> <52095712.4080404@oracle.com>
	<008b01ce97ae$583efdf0$08bcf9d0$@oracle.com>
Message-ID: <52096C58.6000304@oracle.com>

|Yumin,||
||
||If I understand correctly, the reason of dumping the classes in a 
separate process using SA is to avoid crashing (in case the system 
dictionary is corrupt).||
||
||But you're already exec'ing SA as the very last step of writing to 
hs_err. Maybe instead of exec SA, just dump the system dict using C code 
within the crashing process (SystemDictionary::print()). ||
||
||If the sys dict is corrupt you will encounter a secondary crash here, 
but that's OK, because ||hs_err_pid*.log already has ||all the 
information that we used to have, so you are not making it any worse. It 
may actually be helpful because now you know for sure that the sys dict 
is corrupt. This is one piece of information that we didn't have.

Also, if the sys dict is corrupt, I doubt SA can produce more meaningful 
data than |||SystemDictionary::print()|. Instead, it may be better to 
have a |
|||||SystemDictionary::print_safely() function that makes more error 
checking|| so it can better handle a partially corrupted sys dict.

- Ioi
||
||
||Since you're doing the dump of classes as the very last step of to 
hs_err, instead of spawning another JVM ||
||On 08/12/2013 03:50 PM, Christian Tornqvist wrote:||
|
> |I agree with Coleen, this change should not be added to the JVM.
>
> Though I'd like to have the tool to create this archive from a core/mdmp. If this is not already present in any of the j*-tools we might want to look into adding it, please work with the serviceability team to determine where this would be best suited.
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com]
> Sent: Monday, August 12, 2013 5:44 PM
> To: Yumin Qi
> Cc: Christian Tornqvist; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; 'hotspot compiler'; 'David Holmes'; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>
>
> Yumin,
>
> I don't think this change should be added to the JVM for the following reasons.
>
> 1. Error handling should only contain safe actions.   We have concerns
> that the SA is not that stable and would prevent getting a real core
> file in many error situations.   You couldn't have tested all error
> situations because these are usually the things we don't know about.
> You also mention that there are currently bugs preventing this feature from working in your first email.
>
> 2. I am not convinced that having a separate jar file with loaded classes (is it a list that SA generates?) would be collected by an error
> reporter.   If it's collected, I don't see how helpful it would be.
> Also a customer may not want their classes disclosed in error reporting.
>
> 3.  This doesn't seem important enough to include as a new feature in
> jdk8 release, which is feature-complete.   I don't see a customer
> request for it.
>
> Coleen
>
> On 08/12/2013 01:00 PM, Yumin Qi wrote:
> |
>> |Chris, David
>>
>>    Yes. This can be after crash with core file, but some time no core
>> file generated (also if the error could not repeat, we will never got
>> information again), so dumping  target process is also a choice. To
>> avoid more confusion, this step was launched at the very last moment,
>> just before raise abort to exit. At this moment, if client process
>> could not attach to the target process it will exit right away.
>>
>> Answers to David:
>>
>> Note that the SA is only present in a full JDK, not a JRE (full or
>> compact profile).
>>    Yes, in code, if no sa-jdi.jar found, skip fork.
>>
>> - What mechanism will the SA try to use to query the VM?
>>
>>    After successfully attached to target process, SA will read via proc
>> APIs and vmStructs (named TYPEDB) to iterate  memory of system
>> dictionary read (only)  from target process to dump class information.
>>
>> - What if the state of the crashed VM stops the SA from being able to
>> attach properly (ie both processes hang)?
>>
>>    That should be an attaching API problem. We haven't watched such
>> case happened so far.
>>
>> - What if it the SA also crashes, will it launch a third VM then a
>> fourth etc?
>>
>>    Definitely don't want to see this happened in a chain. The solution
>> may use a property such as
>> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into
>> SA process, at launching call, check if the property set, if set, do
>> not fork. When SA process died, it will generate core file first, note
>> the target process still waiting for its exit, so when target exit,
>> the core file (if both use default core as name) will be override by
>> target. The SA process will only leave a hs_err_pid*.log file. (? read
>> such property in handler is possible?)
>>
>>   Also what is the nature of this dump? How big is it? Where will it go?
>>   The jars includes *app.jar and *boot.jar, the later usually can be
>> ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent.
>> The app.jar will contain all classes by customer, so we can do
>> whatever we can to the jar.
>>
>>
>> Thanks
>> Yumin
>>
>>
>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>> |
>>> |Hi Yumin,
>>>
>>> The idea is to do as little as possible in the VM error handler,
>>> since we've crashed for some reason we don't know what state the
>>> process is in and we have to be extremely careful in when we're
>>> gathering the information. This seems like a step that is risky for
>>> all of the reasons David mentioned below.
>>>
>>> It's also information that can easily be extracted post-mortem from
>>> the core/mdmp using the method you described for OSX, so gathering
>>> this at the time of a crash seems like an unnecessary risk.
>>>
>>> Thanks,
>>> Christian
>>>
>>> -----Original Message-----
>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
>>> David Holmes
>>> Sent: Monday, August 12, 2013 1:56 AM
>>> To: Yumin Qi
>>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>>
>>> Hi Yumin,
>>>
>>> Note that the SA is only present in a full JDK, not a JRE (full or
>>> compact profile).
>>>
>>> I have quite a few concerns with this:
>>>
>>> We already do a lot of things that are not valid to be done from a
>>> signal handling context but this really takes that to an extreme.
>>> Doing fork-exec from a signal handler seems like a recipe for
>>> disaster (Note the existing onError facility is typically used for
>>> synchronous failures.)
>>>
>>> The idea of launching a second VM to try and query a VM that has
>>> crashed also seems somewhat problematic:
>>> - What mechanism will the SA try to use to query the VM?
>>> - What if the state of the crashed VM stops the SA from being able to
>>> attach properly (ie both processes hang)?
>>> - What if it the SA also crashes, will it launch a third VM then a
>>> fourth etc?
>>>
>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>
>>> Thanks,
>>> David
>>>
>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>> |
>>>> |Hi, all
>>>>
>>>>      I would like to have your review for
>>>>
>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>>
>>>> Description: When JVM crashed, we also want to check the application
>>>> class files especially we got core file from customers.  The
>>>> aftermath analysis will benefit from all loaded java classes
>>>> available. In this change, spawn another process running SA to do
>>>> the job when JVM crashes, this way also avoid further messing up
>>>> with the error report which already in signal handler.
>>>>
>>>> Note: The test has done with following two bugs worked around:
>>>>      8022655: ClassDump ignored jarStream setting (This will be fixed
>>>> and integrated by Kevin Walls soon)
>>>>      8011888: sa.js: TypeError: [object JSAdapter] has no such
>>>> function "__has__" (Not know when it will be integrated)
>>>>      That is, without those two fixed, the jars of loaded classes
>>>> will not be successfully dumped.
>>>>      Also, on MacOS it requires security access permission to attach
>>>> to another process, so omit doing so. To get loaded jar file s, with
>>>> core file available (on all platforms), one can (only after this
>>>> change) do
>>>>
>>>>      $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>> |
>> |
>> |
> |
>
> |
|
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130812/f0a0215b/attachment.html 

From yumin.qi at oracle.com  Mon Aug 12 16:47:21 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 12 Aug 2013 16:47:21 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <52096C58.6000304@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com> <52095712.4080404@oracle.com>
	<008b01ce97ae$583efdf0$08bcf9d0$@oracle.com>
	<52096C58.6000304@oracle.com>
Message-ID: <52097409.60700@oracle.com>

Ioi,

On 8/12/2013 4:14 PM, Ioi Lam wrote:
> |Yumin,||
> ||
> ||If I understand correctly, the reason of dumping the classes in a 
> separate process using SA is to avoid crashing (in case the system 
> dictionary is corrupt).||
> ||
> |
|Yes.|
> |||But you're already exec'ing SA as the very last step of writing to 
> hs_err. Maybe instead of exec SA, just dump the system dict using C 
> code within the crashing process (SystemDictionary::print()). ||
> ||
> ||If the sys dict is corrupt you will encounter a secondary crash 
> here, but that's OK, because ||hs_err_pid*.log already has ||all the 
> information that we used to have, so you are not making it any worse. 
> It may actually be helpful because now you know for sure that the sys 
> dict is corrupt. This is one piece of information that we didn't have.
>
> Also, if the sys dict is corrupt, I doubt SA can produce more 
> meaningful data than |||SystemDictionary::print()|. Instead, it may be 
> better to have a |
> |||||SystemDictionary::print_safely() function that makes more error 
> checking|| so it can better handle a partially corrupted sys dict.
>
> |
|SA will throw exception on encounter corrupted data in sys dictionary.
Let me think about your suggestion which I think is a good way to make 
it work.

Thanks
Yumin
|
> |- Ioi
> ||
> ||
> ||Since you're doing the dump of classes as the very last step of to 
> hs_err, instead of spawning another JVM ||
> ||On 08/12/2013 03:50 PM, Christian Tornqvist wrote:||
> |
>> |I agree with Coleen, this change should not be added to the JVM.
>>
>> Though I'd like to have the tool to create this archive from a core/mdmp. If this is not already present in any of the j*-tools we might want to look into adding it, please work with the serviceability team to determine where this would be best suited.
>>
>> Thanks,
>> Christian
>>
>> -----Original Message-----
>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com]
>> Sent: Monday, August 12, 2013 5:44 PM
>> To: Yumin Qi
>> Cc: Christian Tornqvist;serviceability-dev at openjdk.java.net  serviceability-dev at openjdk.java.net; 'hotspot compiler'; 'David Holmes';hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>
>>
>> Yumin,
>>
>> I don't think this change should be added to the JVM for the following reasons.
>>
>> 1. Error handling should only contain safe actions.   We have concerns
>> that the SA is not that stable and would prevent getting a real core
>> file in many error situations.   You couldn't have tested all error
>> situations because these are usually the things we don't know about.
>> You also mention that there are currently bugs preventing this feature from working in your first email.
>>
>> 2. I am not convinced that having a separate jar file with loaded classes (is it a list that SA generates?) would be collected by an error
>> reporter.   If it's collected, I don't see how helpful it would be.
>> Also a customer may not want their classes disclosed in error reporting.
>>
>> 3.  This doesn't seem important enough to include as a new feature in
>> jdk8 release, which is feature-complete.   I don't see a customer
>> request for it.
>>
>> Coleen
>>
>> On 08/12/2013 01:00 PM, Yumin Qi wrote:
>> |
>>> |Chris, David
>>>
>>>    Yes. This can be after crash with core file, but some time no core
>>> file generated (also if the error could not repeat, we will never got
>>> information again), so dumping  target process is also a choice. To
>>> avoid more confusion, this step was launched at the very last moment,
>>> just before raise abort to exit. At this moment, if client process
>>> could not attach to the target process it will exit right away.
>>>
>>> Answers to David:
>>>
>>> Note that the SA is only present in a full JDK, not a JRE (full or
>>> compact profile).
>>>    Yes, in code, if no sa-jdi.jar found, skip fork.
>>>
>>> - What mechanism will the SA try to use to query the VM?
>>>
>>>    After successfully attached to target process, SA will read via proc
>>> APIs and vmStructs (named TYPEDB) to iterate  memory of system
>>> dictionary read (only)  from target process to dump class information.
>>>
>>> - What if the state of the crashed VM stops the SA from being able to
>>> attach properly (ie both processes hang)?
>>>
>>>    That should be an attaching API problem. We haven't watched such
>>> case happened so far.
>>>
>>> - What if it the SA also crashes, will it launch a third VM then a
>>> fourth etc?
>>>
>>>    Definitely don't want to see this happened in a chain. The solution
>>> may use a property such as
>>> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into
>>> SA process, at launching call, check if the property set, if set, do
>>> not fork. When SA process died, it will generate core file first, note
>>> the target process still waiting for its exit, so when target exit,
>>> the core file (if both use default core as name) will be override by
>>> target. The SA process will only leave a hs_err_pid*.log file. (? read
>>> such property in handler is possible?)
>>>
>>>   Also what is the nature of this dump? How big is it? Where will it go?
>>>   The jars includes *app.jar and *boot.jar, the later usually can be
>>> ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent.
>>> The app.jar will contain all classes by customer, so we can do
>>> whatever we can to the jar.
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>>> |
>>>> |Hi Yumin,
>>>>
>>>> The idea is to do as little as possible in the VM error handler,
>>>> since we've crashed for some reason we don't know what state the
>>>> process is in and we have to be extremely careful in when we're
>>>> gathering the information. This seems like a step that is risky for
>>>> all of the reasons David mentioned below.
>>>>
>>>> It's also information that can easily be extracted post-mortem from
>>>> the core/mdmp using the method you described for OSX, so gathering
>>>> this at the time of a crash seems like an unnecessary risk.
>>>>
>>>> Thanks,
>>>> Christian
>>>>
>>>> -----Original Message-----
>>>> From:hotspot-compiler-dev-bounces at openjdk.java.net
>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
>>>> David Holmes
>>>> Sent: Monday, August 12, 2013 1:56 AM
>>>> To: Yumin Qi
>>>> Cc: hotspot compiler;hotspot-runtime-dev at openjdk.java.net
>>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>>>
>>>> Hi Yumin,
>>>>
>>>> Note that the SA is only present in a full JDK, not a JRE (full or
>>>> compact profile).
>>>>
>>>> I have quite a few concerns with this:
>>>>
>>>> We already do a lot of things that are not valid to be done from a
>>>> signal handling context but this really takes that to an extreme.
>>>> Doing fork-exec from a signal handler seems like a recipe for
>>>> disaster (Note the existing onError facility is typically used for
>>>> synchronous failures.)
>>>>
>>>> The idea of launching a second VM to try and query a VM that has
>>>> crashed also seems somewhat problematic:
>>>> - What mechanism will the SA try to use to query the VM?
>>>> - What if the state of the crashed VM stops the SA from being able to
>>>> attach properly (ie both processes hang)?
>>>> - What if it the SA also crashes, will it launch a third VM then a
>>>> fourth etc?
>>>>
>>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>>> |
>>>>> |Hi, all
>>>>>
>>>>>      I would like to have your review for
>>>>>
>>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>>>
>>>>> Description: When JVM crashed, we also want to check the application
>>>>> class files especially we got core file from customers.  The
>>>>> aftermath analysis will benefit from all loaded java classes
>>>>> available. In this change, spawn another process running SA to do
>>>>> the job when JVM crashes, this way also avoid further messing up
>>>>> with the error report which already in signal handler.
>>>>>
>>>>> Note: The test has done with following two bugs worked around:
>>>>>      8022655: ClassDump ignored jarStream setting (This will be fixed
>>>>> and integrated by Kevin Walls soon)
>>>>>      8011888: sa.js: TypeError: [object JSAdapter] has no such
>>>>> function "__has__" (Not know when it will be integrated)
>>>>>      That is, without those two fixed, the jars of loaded classes
>>>>> will not be successfully dumped.
>>>>>      Also, on MacOS it requires security access permission to attach
>>>>> to another process, so omit doing so. To get loaded jar file s, with
>>>>> core file available (on all platforms), one can (only after this
>>>>> change) do
>>>>>
>>>>>      $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
>>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>> |
>>> |
>>> |
>> |
>>
>> |
> |
> | 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130812/76e0c955/attachment-0001.html 

From matthew.e.briggs at gmail.com  Mon Aug 12 17:40:57 2013
From: matthew.e.briggs at gmail.com (Matthew Briggs)
Date: Mon, 12 Aug 2013 20:40:57 -0400
Subject: [PATCH] Improve Windows Minidump File Specification
In-Reply-To: <CAH5Wu=UqryS244Xb6fHvkFVyrqD067YJG7Q1SqbLQp5jfyTBvg@mail.gmail.com>
References: <CAH5Wu=USo_DEgw9_CTEeWdOOammgjLQdqSTZL84i-LKoik5DPQ@mail.gmail.com>
	<51F5EE00.4070704@oracle.com>
	<CAH5Wu=UqryS244Xb6fHvkFVyrqD067YJG7Q1SqbLQp5jfyTBvg@mail.gmail.com>
Message-ID: <CAH5Wu=U+3y52H76KuPBz9sPHSGUNjJpVZ9MEYAPnG3s-8bBPxg@mail.gmail.com>

David,

Just a quick follow up to let you know that I received confirmation
that my OCA has been processed.  If there's anything else I can do to
help move my feature request/patch forward, please let me know.

Thanks,
Matt

On Mon, Jul 29, 2013 at 11:02 PM, Matthew Briggs
<matthew.e.briggs at gmail.com> wrote:
> Hello David,
>
> Thank you very much for the follow up.  Per your response, I've:
>
> - Signed the Oracle Contributor Agreement and emailed a scanned image
> of my completed form to oracle-ca_us at oracle.com
>
> - For tracking purposes, I've created a new feature request in the Bug
> Database (http://bugs.sun.com/bugdatabase/).  The Bug ID is 9005569.
>
> - I realized my original patch posting didn't address some
> alternatives I had considered, so I added some information about that
> to the feature request as well.
>
> Thanks again!
> Matt
>
> On Mon, Jul 29, 2013 at 12:22 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Matthew,
>>
>> Welcome!
>>
>> The contribution process is described here:
>>
>> http://openjdk.java.net/contribute/
>>
>> First you need to sign the OCA:
>>
>> http://www.oracle.com/technetwork/oca-405177.pdf
>>
>> Meanwhile someone will hopefully be able to review this and sponsor it for
>> you if deemed suitable.
>>
>> Thanks,
>> David
>>
>>
>> On 29/07/2013 1:50 AM, Matthew Briggs wrote:
>>>
>>> Hello,
>>>
>>> In running a Java application in a Windows Service context, minidump
>>> files have proven helpful in diagnosing crashes due to faulty native
>>> code (invoked through JNI).  In production contexts I'm familiar with,
>>> these minidumps are often not produced, though, due to a combination of
>>> configuration and limitations in the JVM's minidump location choices.
>>>   Specifically, the JVM only allows for minidump files to be created in
>>> the working directory of the Windows Service process.  A typical
>>> production deployment runs the Windows Service under the limited NETWORK
>>> SERVICE account, which in particular cannot write to its working
>>> directory (usually located under C:\Program Files).
>>>
>>> The included patch establishes a new -XX:MinidumpFile JVM option, in the
>>> spirit of the existing -XX:ErrorFile option.  The handling code for the
>>> latter is adapted to maintain similar structure and functionality.  A
>>> Windows minidump file may thus be specified by a user (including support
>>> for %p syntax), falling back to a default filename targeted in the
>>> process working directory and then an OS temporary directory.
>>>
>>> I've manually tested the patch using a simple Java application that
>>> intentionally causes an access violation through JNI invocation of
>>> native code.  I've tested explicit user specification of
>>> -XX:MinidumpFile, with and without %p,  along with the two fallback cases.
>>>
>>> This is my first interaction with the OpenJDK community, so I apologize
>>> in advance if I've failed to follow proper patch submission guidelines
>>> and procedures.  I'm eager to learn more about how the community
>>> operates, and to hear if this patch in particular is of interest.  Any
>>> feedback is appreciated.
>>>
>>> Thanks,
>>> Matt
>>>
>>> diff -r 9d7b55c8a0c4 src/os/windows/vm/os_windows.cpp
>>> --- a/src/os/windows/vm/os_windows.cppThu Jul 25 03:18:31 2013 -0700
>>> +++ b/src/os/windows/vm/os_windows.cppSun Jul 28 14:50:32 2013 +0100
>>>
>>> @@ -934,6 +934,55 @@
>>>     }
>>>   }
>>> +/** Expand a pattern into a buffer starting at pos and create a file
>>> using constructed path */
>>> +static HANDLE expand_and_create(const char* pattern, char* buf, size_t
>>> buflen, size_t pos) {
>>> +  HANDLE file = INVALID_HANDLE_VALUE;
>>> +  if (Arguments::copy_expand_pid(pattern, strlen(pattern), &buf[pos],
>>> buflen - pos)) {
>>> +file = CreateFile(buf, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
>>>
>>> FILE_ATTRIBUTE_NORMAL, NULL);
>>> +  }
>>> +  return file;
>>> +}
>>> +
>>> +/**
>>> + * Construct file name for a minidump file and return it's file handle.
>>> + * Name and location depends on pattern, default_pattern params and
>>> access
>>> + * permissions.
>>> + */
>>> +static HANDLE prepare_minidump_file(const char* pattern, const char*
>>> default_pattern, char* buf, size_t buflen) {
>>> +  HANDLE file = INVALID_HANDLE_VALUE;
>>> +
>>> +  // If possible, use specified pattern to construct file name
>>> +  if (pattern != NULL) {
>>> +    file = expand_and_create(pattern, buf, buflen, 0);
>>> +  }
>>> +
>>> +  // Either user didn't specify, or the user's location failed,
>>> +  // so use the default name in the current directory
>>> +  if (file == INVALID_HANDLE_VALUE) {
>>> +    const char* cwd = os::get_current_directory(buf, buflen);
>>> +    if (cwd != NULL) {
>>> +      size_t pos = strlen(cwd);
>>> +      int fsep_len = jio_snprintf(&buf[pos], buflen-pos, "%s",
>>> os::file_separator());
>>> +      pos += fsep_len;
>>> +      if (fsep_len > 0) {
>>> +        file = expand_and_create(default_pattern, buf, buflen, pos);
>>> +      }
>>> +    }
>>> +  }
>>> +
>>> +  // try temp directory if it exists.
>>> +  if (file == INVALID_HANDLE_VALUE) {
>>> +    const char* tmpdir = os::get_temp_directory();
>>> +    if (tmpdir != NULL && strlen(tmpdir) > 0) {
>>> +      int pos = jio_snprintf(buf, buflen, "%s%s", tmpdir,
>>> os::file_separator());
>>> +      if (pos > 0) {
>>> +        file = expand_and_create(default_pattern, buf, buflen, pos);
>>> +      }
>>> +    }
>>> +  }
>>> +
>>> +  return file;
>>> +}
>>>   static BOOL  (WINAPI *_MiniDumpWriteDump)  ( HANDLE, DWORD, HANDLE,
>>> MINIDUMP_TYPE, PMINIDUMP_EXCEPTION_INFORMATION,
>>>
>>>   PMINIDUMP_USER_STREAM_INFORMATION, PMINIDUMP_CALLBACK_INFORMATION);
>>> @@ -948,7 +997,6 @@
>>>     DWORD processId = GetCurrentProcessId();
>>>     HANDLE dumpFile;
>>>     MINIDUMP_TYPE dumpType;
>>> -  static const char* cwd;
>>>   // Default is to always create dump for debug builds, on product
>>> builds only dump on server versions of Windows.
>>>   #ifndef ASSERT
>>> @@ -994,10 +1042,7 @@
>>>       MiniDumpWithUnloadedModules);
>>>   #endif
>>> -  cwd = get_current_directory(NULL, 0);
>>> -  jio_snprintf(buffer, bufferSize, "%s\\hs_err_pid%u.mdmp",cwd,
>>> current_process_id());
>>> -  dumpFile = CreateFile(buffer, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
>>> FILE_ATTRIBUTE_NORMAL, NULL);
>>> -
>>> +  dumpFile = prepare_minidump_file(MinidumpFile, "hs_err_pid%p.mdmp",
>>> buffer, bufferSize);
>>>     if (dumpFile == INVALID_HANDLE_VALUE) {
>>>       VMError::report_coredump_status("Failed to create file for
>>> dumping", false);
>>>       return;
>>> diff -r 9d7b55c8a0c4 src/share/vm/runtime/globals.hpp
>>> --- a/src/share/vm/runtime/globals.hppThu Jul 25 03:18:31 2013 -0700
>>> +++ b/src/share/vm/runtime/globals.hppSun Jul 28 14:50:32 2013 +0100
>>>
>>> @@ -825,6 +825,10 @@
>>>     product(bool, CreateMinidumpOnCrash, false,
>>>        \
>>>             "Create minidump on VM fatal error")
>>>       \
>>>
>>>       \
>>> +  product(ccstr, MinidumpFile, NULL,
>>>       \
>>> +         "If a minidump is created, save to this file"
>>>       \
>>> +         "[default: ./hs_err_pid%p.mdmp] (%p replaced with pid)")
>>>      \
>>> +
>>>       \
>>>     product_pd(bool, UseOSErrorReporting,
>>>        \
>>>             "Let VM fatal error propagate to the OS (ie. WER on
>>> Windows)")    \
>>>
>>>       \
>>>
>>

From coleen.phillimore at oracle.com  Mon Aug 12 18:09:50 2013
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 13 Aug 2013 01:09:50 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8009728:
	nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
Message-ID: <20130813010952.E526B487E9@hg.openjdk.java.net>

Changeset: 85147f28faba
Author:    coleenp
Date:      2013-08-12 17:24 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/85147f28faba

8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
Summary: ActiveMethodOopsCache was used to keep track of old versions of some methods that are cached in Universe but is buggy with permgen removal and not needed anymore
Reviewed-by: sspitsyn, dcubed, mseledtsov

! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! test/runtime/RedefineObject/Agent.java
! test/runtime/RedefineObject/TestRedefineObject.java
+ test/runtime/RedefineObject/WalkThroughInvoke.java


From christian.thalinger at oracle.com  Mon Aug 12 18:12:03 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 12 Aug 2013 18:12:03 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <52095712.4080404@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com> <52095712.4080404@oracle.com>
Message-ID: <033D0E0C-963F-4272-ABF1-028F4935F4C9@oracle.com>


On Aug 12, 2013, at 2:43 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> 
> Yumin,
> 
> I don't think this change should be added to the JVM for the following reasons.

This change is something that I (kind of) requested from Yumin since it would help to reproduce crashes in the compilers.  Getting replay data after the fact can be very tricky (given all the system library interactions or a broken SA; see below).

> 
> 1. Error handling should only contain safe actions.   We have concerns that the SA is not that stable

?which is a problem, I agree.  To make it more stable we need to use it so we can detect problems early.  

Having the SA dump data when we crash in the compiler can be one of these usages.  The SA logic would be exercised during our internal testing and could be fixed before the release.  Right now the situation is we see a customer crash, we want to run the SA and notice that it's broken.  That's too late.

> and would prevent getting a real core file in many error situations.   You couldn't have tested all error situations because these are usually the things we don't know about.   You also mention that there are currently bugs preventing this feature from working in your first email.
> 
> 2. I am not convinced that having a separate jar file with loaded classes (is it a list that SA generates?) would be collected by an error reporter.   If it's collected, I don't see how helpful it would be.

As mentioned above, it's required to replay compilations.

>  Also a customer may not want their classes disclosed in error reporting.

They don't have to if they don't want to.

-- Chris

> 
> 3.  This doesn't seem important enough to include as a new feature in jdk8 release, which is feature-complete.   I don't see a customer request for it.
> 
> Coleen
> 
> On 08/12/2013 01:00 PM, Yumin Qi wrote:
>> Chris, David
>> 
>>  Yes. This can be after crash with core file, but some time no core file generated (also if the error could not repeat, we will never got information again), so dumping  target process is also a choice. To avoid more confusion, this step was launched at the very last moment, just before raise abort to exit. At this moment, if client process could not attach to the target process it will exit right away.
>> 
>> Answers to David:
>> 
>> Note that the SA is only present in a full JDK, not a JRE (full or compact profile).
>>  Yes, in code, if no sa-jdi.jar found, skip fork.
>> 
>> - What mechanism will the SA try to use to query the VM?
>> 
>>  After successfully attached to target process, SA will read via proc APIs and vmStructs (named TYPEDB) to iterate  memory of system dictionary read (only)  from target process to dump class information.
>> 
>> - What if the state of the crashed VM stops the SA from being able to attach properly (ie both processes hang)?
>> 
>>  That should be an attaching API problem. We haven't watched such case happened so far.
>> 
>> - What if it the SA also crashes, will it launch a third VM then a fourth etc?
>> 
>>  Definitely don't want to see this happened in a chain. The solution may use a property such as sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into SA process, at launching call, check if the property set, if set, do not fork. When SA process died, it will generate core file first, note the target process still waiting for its exit, so when target exit, the core file (if both use default core as name) will be override by target. The SA process will only leave a hs_err_pid*.log file. (? read such property in handler is possible?)
>> 
>> Also what is the nature of this dump? How big is it? Where will it go?
>> The jars includes *app.jar and *boot.jar, the later usually can be ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent. The app.jar will contain all classes by customer, so we can do whatever we can to the jar.
>> 
>> 
>> Thanks
>> Yumin
>> 
>> 
>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>>> Hi Yumin,
>>> 
>>> The idea is to do as little as possible in the VM error handler, since we've crashed for some reason we don't know what state the process is in and we have to be extremely careful in when we're gathering the information. This seems like a step that is risky for all of the reasons David mentioned below.
>>> 
>>> It's also information that can easily be extracted post-mortem from the core/mdmp using the method you described for OSX, so gathering this at the time of a crash seems like an unnecessary risk.
>>> 
>>> Thanks,
>>> Christian
>>> 
>>> -----Original Message-----
>>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
>>> Sent: Monday, August 12, 2013 1:56 AM
>>> To: Yumin Qi
>>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>> 
>>> Hi Yumin,
>>> 
>>> Note that the SA is only present in a full JDK, not a JRE (full or compact profile).
>>> 
>>> I have quite a few concerns with this:
>>> 
>>> We already do a lot of things that are not valid to be done from a signal handling context but this really takes that to an extreme. Doing fork-exec from a signal handler seems like a recipe for disaster (Note the existing onError facility is typically used for synchronous failures.)
>>> 
>>> The idea of launching a second VM to try and query a VM that has crashed also seems somewhat problematic:
>>> - What mechanism will the SA try to use to query the VM?
>>> - What if the state of the crashed VM stops the SA from being able to attach properly (ie both processes hang)?
>>> - What if it the SA also crashes, will it launch a third VM then a fourth etc?
>>> 
>>> Also what is the nature of this dump? How big is it? Where will it go?
>>> 
>>> Thanks,
>>> David
>>> 
>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>>> Hi, all
>>>> 
>>>>    I would like to have your review for
>>>> 
>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>> 
>>>> Description: When JVM crashed, we also want to check the application
>>>> class files especially we got core file from customers.  The aftermath
>>>> analysis will benefit from all loaded java classes available. In this
>>>> change, spawn another process running SA to do the job when JVM
>>>> crashes, this way also avoid further messing up with the error report
>>>> which already in signal handler.
>>>> 
>>>> Note: The test has done with following two bugs worked around:
>>>>    8022655: ClassDump ignored jarStream setting (This will be fixed
>>>> and integrated by Kevin Walls soon)
>>>>    8011888: sa.js: TypeError: [object JSAdapter] has no such function
>>>> "__has__" (Not know when it will be integrated)
>>>>    That is, without those two fixed, the jars of loaded classes will
>>>> not be successfully dumped.
>>>>    Also, on MacOS it requires security access permission to attach to
>>>> another process, so omit doing so. To get loaded jar file s, with core
>>>> file available (on all platforms), one can (only after this
>>>> change) do
>>>> 
>>>>    $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>> 
>>>> 
>>>> Thanks
>>>> Yumin
>> 
> 


From yumin.qi at oracle.com  Mon Aug 12 20:43:54 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 12 Aug 2013 20:43:54 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <52095712.4080404@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com> <52095712.4080404@oracle.com>
Message-ID: <5209AB7A.8090503@oracle.com>

Coleen,

   Chris Thalinger  already answered some of your concerns. For jar file 
which dumped in this change, compiler replay has added functions to SA 
to dump out replay jars against core file. Since customer is the one 
wants us to fix problems in VM, the disclosure of such jar to us should 
be OK I think, any way if we have core file, we already have the loaded 
classes.
   This should mainly be focused on dump jars as possible at the last 
stage of error reporter. I chose using SA since with c++ to implement 
same functionality I have to use zip file operation to do so, which is 
not a fit at such condition, but in SA the same operation ready for use. 
The only case we could not get jar files is no core file available, in 
such case, this change will supply an alternate.

   Looks this need more discussion for further decision.

Thanks
Yumin


On 8/12/2013 2:43 PM, Coleen Phillimore wrote:
>
> Yumin,
>
> I don't think this change should be added to the JVM for the following 
> reasons.
>
> 1. Error handling should only contain safe actions.   We have concerns 
> that the SA is not that stable and would prevent getting a real core 
> file in many error situations.   You couldn't have tested all error 
> situations because these are usually the things we don't know about.   
> You also mention that there are currently bugs preventing this feature 
> from working in your first email.
>
> 2. I am not convinced that having a separate jar file with loaded 
> classes (is it a list that SA generates?) would be collected by an 
> error reporter.   If it's collected, I don't see how helpful it would 
> be.  Also a customer may not want their classes disclosed in error 
> reporting.
>
> 3.  This doesn't seem important enough to include as a new feature in 
> jdk8 release, which is feature-complete.   I don't see a customer 
> request for it.
>
> Coleen
>
> On 08/12/2013 01:00 PM, Yumin Qi wrote:
>> Chris, David
>>
>>   Yes. This can be after crash with core file, but some time no core 
>> file generated (also if the error could not repeat, we will never got 
>> information again), so dumping  target process is also a choice. To 
>> avoid more confusion, this step was launched at the very last moment, 
>> just before raise abort to exit. At this moment, if client process 
>> could not attach to the target process it will exit right away.
>>
>> Answers to David:
>>
>> Note that the SA is only present in a full JDK, not a JRE (full or 
>> compact profile).
>>   Yes, in code, if no sa-jdi.jar found, skip fork.
>>
>> - What mechanism will the SA try to use to query the VM?
>>
>>   After successfully attached to target process, SA will read via 
>> proc APIs and vmStructs (named TYPEDB) to iterate  memory of system 
>> dictionary read (only)  from target process to dump class information.
>>
>> - What if the state of the crashed VM stops the SA from being able to 
>> attach properly (ie both processes hang)?
>>
>>   That should be an attaching API problem. We haven't watched such 
>> case happened so far.
>>
>> - What if it the SA also crashes, will it launch a third VM then a 
>> fourth etc?
>>
>>   Definitely don't want to see this happened in a chain. The solution 
>> may use a property such as 
>> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into 
>> SA process, at launching call, check if the property set, if set, do 
>> not fork. When SA process died, it will generate core file first, 
>> note the target process still waiting for its exit, so when target 
>> exit, the core file (if both use default core as name) will be 
>> override by target. The SA process will only leave a hs_err_pid*.log 
>> file. (? read such property in handler is possible?)
>>
>>  Also what is the nature of this dump? How big is it? Where will it go?
>>  The jars includes *app.jar and *boot.jar, the later usually can be 
>> ignored (rt.jar etc system jars) unless it's rewritten by JVMTI 
>> agent. The app.jar will contain all classes by customer, so we can do 
>> whatever we can to the jar.
>>
>>
>> Thanks
>> Yumin
>>
>>
>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>>> Hi Yumin,
>>>
>>> The idea is to do as little as possible in the VM error handler, 
>>> since we've crashed for some reason we don't know what state the 
>>> process is in and we have to be extremely careful in when we're 
>>> gathering the information. This seems like a step that is risky for 
>>> all of the reasons David mentioned below.
>>>
>>> It's also information that can easily be extracted post-mortem from 
>>> the core/mdmp using the method you described for OSX, so gathering 
>>> this at the time of a crash seems like an unnecessary risk.
>>>
>>> Thanks,
>>> Christian
>>>
>>> -----Original Message-----
>>> From: hotspot-compiler-dev-bounces at openjdk.java.net 
>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of 
>>> David Holmes
>>> Sent: Monday, August 12, 2013 1:56 AM
>>> To: Yumin Qi
>>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>>
>>> Hi Yumin,
>>>
>>> Note that the SA is only present in a full JDK, not a JRE (full or 
>>> compact profile).
>>>
>>> I have quite a few concerns with this:
>>>
>>> We already do a lot of things that are not valid to be done from a 
>>> signal handling context but this really takes that to an extreme. 
>>> Doing fork-exec from a signal handler seems like a recipe for 
>>> disaster (Note the existing onError facility is typically used for 
>>> synchronous failures.)
>>>
>>> The idea of launching a second VM to try and query a VM that has 
>>> crashed also seems somewhat problematic:
>>> - What mechanism will the SA try to use to query the VM?
>>> - What if the state of the crashed VM stops the SA from being able 
>>> to attach properly (ie both processes hang)?
>>> - What if it the SA also crashes, will it launch a third VM then a 
>>> fourth etc?
>>>
>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>
>>> Thanks,
>>> David
>>>
>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>>> Hi, all
>>>>
>>>>     I would like to have your review for
>>>>
>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>>
>>>> Description: When JVM crashed, we also want to check the application
>>>> class files especially we got core file from customers.  The aftermath
>>>> analysis will benefit from all loaded java classes available. In this
>>>> change, spawn another process running SA to do the job when JVM
>>>> crashes, this way also avoid further messing up with the error report
>>>> which already in signal handler.
>>>>
>>>> Note: The test has done with following two bugs worked around:
>>>>     8022655: ClassDump ignored jarStream setting (This will be fixed
>>>> and integrated by Kevin Walls soon)
>>>>     8011888: sa.js: TypeError: [object JSAdapter] has no such function
>>>> "__has__" (Not know when it will be integrated)
>>>>     That is, without those two fixed, the jars of loaded classes will
>>>> not be successfully dumped.
>>>>     Also, on MacOS it requires security access permission to attach to
>>>> another process, so omit doing so. To get loaded jar file s, with core
>>>> file available (on all platforms), one can (only after this
>>>> change) do
>>>>
>>>>     $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>
>


From christian.tornqvist at oracle.com  Mon Aug 12 22:17:57 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Tue, 13 Aug 2013 01:17:57 -0400
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <033D0E0C-963F-4272-ABF1-028F4935F4C9@oracle.com>
References: <52081FF6.4040205@oracle.com>
	<5208790D.9010309@oracle.com>	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>	<520914A1.8050905@oracle.com>
	<52095712.4080404@oracle.com>
	<033D0E0C-963F-4272-ABF1-028F4935F4C9@oracle.com>
Message-ID: <00a301ce97e4$7b2fc930$718f5b90$@oracle.com>

Hi Chris,

>The SA logic would be exercised during our internal testing and could be
fixed before the release.  Right now the situation is we see a >customer
crash, we want to run the SA and notice that it's broken.  That's too late.

This is an issue with our current testing of the SA. This should be
addressed by making sure our test works and covers the functionality of the
SA, not by making the JVM dependent on the SA.

Thanks,
Christian

-----Original Message-----
From: hotspot-runtime-dev-bounces at openjdk.java.net
[mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Christian
Thalinger
Sent: Monday, August 12, 2013 9:12 PM
To: Coleen Phillimore
Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net;
'hotspot compiler'; hotspot-runtime-dev at openjdk.java.net; 'David Holmes'
Subject: Re: RFR: 8020962: dump loaded java classes when vm crash


On Aug 12, 2013, at 2:43 PM, Coleen Phillimore
<coleen.phillimore at oracle.com> wrote:

> 
> Yumin,
> 
> I don't think this change should be added to the JVM for the following
reasons.

This change is something that I (kind of) requested from Yumin since it
would help to reproduce crashes in the compilers.  Getting replay data after
the fact can be very tricky (given all the system library interactions or a
broken SA; see below).

> 
> 1. Error handling should only contain safe actions.   We have concerns
that the SA is not that stable

.which is a problem, I agree.  To make it more stable we need to use it so
we can detect problems early.  

Having the SA dump data when we crash in the compiler can be one of these
usages.  The SA logic would be exercised during our internal testing and
could be fixed before the release.  Right now the situation is we see a
customer crash, we want to run the SA and notice that it's broken.  That's
too late.

> and would prevent getting a real core file in many error situations.   You
couldn't have tested all error situations because these are usually the
things we don't know about.   You also mention that there are currently bugs
preventing this feature from working in your first email.
> 
> 2. I am not convinced that having a separate jar file with loaded classes
(is it a list that SA generates?) would be collected by an error reporter.
If it's collected, I don't see how helpful it would be.

As mentioned above, it's required to replay compilations.

>  Also a customer may not want their classes disclosed in error reporting.

They don't have to if they don't want to.

-- Chris

> 
> 3.  This doesn't seem important enough to include as a new feature in jdk8
release, which is feature-complete.   I don't see a customer request for it.
> 
> Coleen
> 
> On 08/12/2013 01:00 PM, Yumin Qi wrote:
>> Chris, David
>> 
>>  Yes. This can be after crash with core file, but some time no core file
generated (also if the error could not repeat, we will never got information
again), so dumping  target process is also a choice. To avoid more
confusion, this step was launched at the very last moment, just before raise
abort to exit. At this moment, if client process could not attach to the
target process it will exit right away.
>> 
>> Answers to David:
>> 
>> Note that the SA is only present in a full JDK, not a JRE (full or
compact profile).
>>  Yes, in code, if no sa-jdi.jar found, skip fork.
>> 
>> - What mechanism will the SA try to use to query the VM?
>> 
>>  After successfully attached to target process, SA will read via proc
APIs and vmStructs (named TYPEDB) to iterate  memory of system dictionary
read (only)  from target process to dump class information.
>> 
>> - What if the state of the crashed VM stops the SA from being able to
attach properly (ie both processes hang)?
>> 
>>  That should be an attaching API problem. We haven't watched such case
happened so far.
>> 
>> - What if it the SA also crashes, will it launch a third VM then a fourth
etc?
>> 
>>  Definitely don't want to see this happened in a chain. The solution 
>> may use a property such as 
>> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into 
>> SA process, at launching call, check if the property set, if set, do 
>> not fork. When SA process died, it will generate core file first, 
>> note the target process still waiting for its exit, so when target 
>> exit, the core file (if both use default core as name) will be 
>> override by target. The SA process will only leave a hs_err_pid*.log 
>> file. (? read such property in handler is possible?)
>> 
>> Also what is the nature of this dump? How big is it? Where will it go?
>> The jars includes *app.jar and *boot.jar, the later usually can be
ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent. The
app.jar will contain all classes by customer, so we can do whatever we can
to the jar.
>> 
>> 
>> Thanks
>> Yumin
>> 
>> 
>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>>> Hi Yumin,
>>> 
>>> The idea is to do as little as possible in the VM error handler, since
we've crashed for some reason we don't know what state the process is in and
we have to be extremely careful in when we're gathering the information.
This seems like a step that is risky for all of the reasons David mentioned
below.
>>> 
>>> It's also information that can easily be extracted post-mortem from the
core/mdmp using the method you described for OSX, so gathering this at the
time of a crash seems like an unnecessary risk.
>>> 
>>> Thanks,
>>> Christian
>>> 
>>> -----Original Message-----
>>> From: hotspot-compiler-dev-bounces at openjdk.java.net 
>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of 
>>> David Holmes
>>> Sent: Monday, August 12, 2013 1:56 AM
>>> To: Yumin Qi
>>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>> 
>>> Hi Yumin,
>>> 
>>> Note that the SA is only present in a full JDK, not a JRE (full or
compact profile).
>>> 
>>> I have quite a few concerns with this:
>>> 
>>> We already do a lot of things that are not valid to be done from a 
>>> signal handling context but this really takes that to an extreme. 
>>> Doing fork-exec from a signal handler seems like a recipe for 
>>> disaster (Note the existing onError facility is typically used for 
>>> synchronous failures.)
>>> 
>>> The idea of launching a second VM to try and query a VM that has crashed
also seems somewhat problematic:
>>> - What mechanism will the SA try to use to query the VM?
>>> - What if the state of the crashed VM stops the SA from being able to
attach properly (ie both processes hang)?
>>> - What if it the SA also crashes, will it launch a third VM then a
fourth etc?
>>> 
>>> Also what is the nature of this dump? How big is it? Where will it go?
>>> 
>>> Thanks,
>>> David
>>> 
>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>>> Hi, all
>>>> 
>>>>    I would like to have your review for
>>>> 
>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>> 
>>>> Description: When JVM crashed, we also want to check the 
>>>> application class files especially we got core file from customers.  
>>>> The aftermath analysis will benefit from all loaded java classes 
>>>> available. In this change, spawn another process running SA to do 
>>>> the job when JVM crashes, this way also avoid further messing up 
>>>> with the error report which already in signal handler.
>>>> 
>>>> Note: The test has done with following two bugs worked around:
>>>>    8022655: ClassDump ignored jarStream setting (This will be fixed 
>>>> and integrated by Kevin Walls soon)
>>>>    8011888: sa.js: TypeError: [object JSAdapter] has no such 
>>>> function "__has__" (Not know when it will be integrated)
>>>>    That is, without those two fixed, the jars of loaded classes 
>>>> will not be successfully dumped.
>>>>    Also, on MacOS it requires security access permission to attach 
>>>> to another process, so omit doing so. To get loaded jar file s, 
>>>> with core file available (on all platforms), one can (only after 
>>>> this
>>>> change) do
>>>> 
>>>>    $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar 
>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>> 
>>>> 
>>>> Thanks
>>>> Yumin
>> 
> 



From calvin.cheung at oracle.com  Mon Aug 12 23:19:46 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Mon, 12 Aug 2013 23:19:46 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52087561.4000409@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
Message-ID: <5209D002.9090604@oracle.com>

Hi David,

I cloned the hotspot repo corresponding to 7u25 b15 and debugged a bit 
more and found that the error was thrown at a very early stage within 
the init_globals() called from create_vm(). Below is the call stack:
      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat st, 
ClassPathEntry * * new_entry, bool lazy)  Line 508    C++
      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
bytes    C++
      jvm.dll!LazyClassPathEntry::open_stream(const char * name) Line 
322 + 0x8 bytes C++
      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
__the_thread__)  Line 898 + 0x17 bytes    C++
      jvm.dll!SystemDictionary::load_instance_class(Symbol * class_name, 
Handle class_loader, Thread * __the_thread__)  Line 1362 + 0x14 bytes    C++
jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * name, 
Handle class_loader, Handle protection_domain, Thread * __the_thread__)  
Line 758 + 0x18 bytes    C++
      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
Handle class_loader, Handle protection_domain, Thread * __the_thread__)  
Line 206 + 0x15 bytes    C++
      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
Thread * __the_thread__)  Line 211 + 0x23 bytes    C++
jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID id, 
int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    C++
jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
limit_id, SystemDictionary::WKID & start_id, Thread * __the_thread__)  
Line 1949 + 0x11 bytes    C++
      jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
__the_thread__)  Line 2011 + 0xf bytes    C++
      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
Line 1904 + 0x9 bytes    C++
      jvm.dll!Universe::genesis(Thread * __the_thread__)  Line 353 + 0x9 
bytes    C++
      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
 >   jvm.dll!init_globals()  Line 114    C++
      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
canTryAgain)  Line 3220 + 0x5 bytes    C++
      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
args)  Line 5133 + 0xd bytes    C++
      java.exe!011013bd()
      [Frames below may be incorrect and/or missing, no symbols loaded 
for java.exe]
      java.exe!01101e2f()
      java.exe!0110c807()
      java.exe!0110a5a1()
      java.exe!0110c845()
      java.exe!0110a62b()
      kernel32.dll!767633aa()
      ntdll.dll!77739ef2()
      ntdll.dll!77739ec5()

The error was thrown in the method below:
bool Exceptions::special_exception(Thread* thread, const char* file, int 
line, Symbol* h_name, const char* message) {
   // bootstrapping check
   if (!Universe::is_fully_initialized()) {
     if (h_name == NULL) {
       // atleast an informative message.
       vm_exit_during_initialization("Exception", message);
     } else {
       vm_exit_during_initialization(h_name, message);               
<=====here
     }
     ShouldNotReachHere();
   }
}

Note that it happened in the early stage during create_vm(), so the 
(!Universe::is_fully_initialized()) was true.

The class it was trying to load was sun/misc/AtomicLongCSImpl which I 
couldn't find in 7u25.
It was going through all the jar files in the bootclasspath and finally 
got to the foo.jar which has 0-byte and got "error in opening jar file" 
and then THROW_MSG().
So I think it's just a coincident in 7u25 where the correct error was 
thrown.

In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class and 
thus it didn't hit the "error in opening jar file" (for the foo.jar) 
early until it passed the point when the vm is considered "initialized" 
- is_init_completed() is true. So when THROW_MSG() was called when it 
tried to load the class specified by the test case ("xxx"), it triggered 
the fatal error in ~ExceptionMark(). Call stack up to the THROWN_MSG() 
as follows:
      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat st, 
ClassPathEntry * * new_entry, bool lazy)  Line 508    C++
      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
bytes    C++
 >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  Line 
322 + 0x8 bytes    C++
      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
__the_thread__)  Line 900 + 0x17 bytes C++
      jvm.dll!SystemDictionary::load_instance_class(Symbol * class_name, 
Handle class_loader, Thread * __the_thread__)  Line 1301 + 0x14 bytes    C++
jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * name, 
Handle class_loader, Handle protection_domain, Thread * __the_thread__)  
Line 779 + 0x18 bytes    C++
      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
Handle class_loader, Handle protection_domain, Thread * __the_thread__)  
Line 232 + 0x15 bytes    C++
      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
Thread * __the_thread__)  Line 237 + 0x23 bytes    C++
      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
name)  Line 773 + 0x12 bytes    C++
      java.dll!69461e8c()
      [Frames below may be incorrect and/or missing, no symbols loaded 
for java.dll]
      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
elem)  Line 207    C++
      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) Line 
375 + 0x11 bytes    C++
      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * thread)  
Line 40 + 0x9 bytes    C++

I'll try using TRAPS all the way through the call chain probably 
starting from ClassLoader::load_classfile().

thanks,
Calvin

On 8/11/2013 10:40 PM, David Holmes wrote:
> Hi Calvin,
>
> I don't think this works. As I said previously the expectations of 
> this code with regard to Java exceptions seems to be that it doesn't 
> expect them at all. If you are using TRAPS etc then it should be used 
> all the way through the call chain. What we have now is this call 
> sequence:
>
> void ClassLoader::initialize() {
>   assert(_package_hash_table == NULL, "should have been initialized by 
> now.");
>   EXCEPTION_MARK;
>   ...
>   setup_bootstrap_search_path();
>     -> update_class_path_entry_list(path, false);
>       ->  create_class_path_entry((char *)path, st, &new_entry, 
> LazyBootClassLoader, CHECK);
>
> So if we return after the call to create_class_path_entry with an 
> exception pending we will crash when we hit the EXCEPTION_MARK.
>
> It may be that the EXCEPTION_MARK needs replacing with an explicit 
> exception check and a vm_exit_during_initialization, if this exception 
> can readily occur at runtime. But further analysis of all this code 
> needs to be undertaken.
>
> David
> -----
>
> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>> I've updated the webrev with 2 changes:
>> 1) added the TRAPS as the last parameter to the
>> create_class_path_entry() method;
>> 2) added a jtreg test case.
>>
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>
>> Please take a look again.
>>
>> One more response in-lined below...
>>
>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>> |I found one version of JDK7 that does not crash:||
>>> ||
>>> sc11136754 ~$
>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>
>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>> Error occurred during initialization of VM
>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>> |
>>
>> |I noticed that it started breaking in 7u40 b01; it was still working
>> with 7u25.
>> It may have something to do with when the set_init_completed() is 
>> called:
>> ExceptionMark::~ExceptionMark() {
>>    if (_thread->has_pending_exception()) {
>>      Handle exception(_thread, _thread->pending_exception());
>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>> recursion
>>      if (is_init_completed()) {
>>        exception->print();
>>        fatal("ExceptionMark destructor expects no pending exceptions");
>>      } else {
>>        vm_exit_during_initialization(exception);
>>      }
>>    }
>> }
>>
>> Before 7u40, I think the code path got to the "else" branch of
>> ~ExceptionMark() and we just printed an error and exit.
>>
>> set_init_completed() is only called from Threads::create_vm() and that
>> method didn't change much between 7u25 and 7u40 except for some NMT
>> initialization - MemTracker::bootstrap_single_thread(),
>> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>>
>> Debugging with hs25, the set_init_completed() always happened before
>> create_class_path_entry() and both calls were done within the same
>> thread - "vm startup".
>>
>> thanks,
>> Calvin
>>
>>
>> |
>>> |||
>>> ||
>>> ||- Ioi
>>> |
>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>> |I found an official version that's closest to the Redhat version
>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>> crashes.||
>>>> ||
>>>> ||sc11136754 ~$
>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>> ||java version "1.6.0_25"||
>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>> ||
>>>> ||java.lang.ClassNotFoundException ||
>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>> ||#||
>>>> ||# A fatal error has been detected by the Java Runtime Environment:||
>>>> ||#||
>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>> tid=140608485558016||
>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>> exceptions||
>>>> ||#||
>>>> ||# JRE version: 6.0_25-b06||
>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>>> linux-amd64 compressed oops)||
>>>> ||# An error report file with more information is saved as:||
>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>> ||#||
>>>> ||# If you would like to submit a bug report, please visit:||
>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>> ||#||
>>>> ||Aborted (core dumped)||
>>>> |
>>>> - Ioi
>>>>
>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>> apparently
>>>>>> works differently
>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed this in
>>>>>> their
>>>>>> own repo??||
>>>>>
>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> ||
>>>>>> |
>>>>>> |==OEL6================================================
>>>>>> ||
>>>>>> ||sc11136754 ~$ uname -a||
>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>> ||sc11136754 ~$ type java||
>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>> ||sc11136754 ~$ java -version||
>>>>>> ||java version "1.6.0_22"||
>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>>> test2||
>>>>>> ||Error occurred during initialization of VM||
>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>> foo.jar||
>>>>>> ||
>>>>>> ==OFFICIAL============================================
>>>>>> ||
>>>>>> sc11136754 ~$ /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>> java version "1.6.0_22"
>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>
>>>>>> #
>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>> #
>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>> tid=140510319580928
>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>> #
>>>>>> # JRE version: 6.0_22-b04
>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>>> linux-amd64 )
>>>>>> # An error report file with more information is saved as:
>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>> #
>>>>>> # If you would like to submit a bug report, please visit:
>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>> #
>>>>>> |
>>>>>> |======================================================
>>>>>> ||
>>>>>> ||- Ioi|
>>>>>>
>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>> Hi Ioi, David,
>>>>>>>
>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>> stand-alone test case that doesn't require truncating JAR files in
>>>>>>>> the JDK:||
>>>>>>>> ||
>>>>>>>> ||=========================||
>>>>>>>> ||/*||
>>>>>>>> ||javac test2.java||
>>>>>>>> ||rm -f foo.jar||
>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>> ||touch foo.jar||
>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>> ||*/||
>>>>>>>> ||
>>>>>>>> ||public class test2 {||
>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>> ||        try {||
>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>> ||            t.printStackTrace();||
>>>>>>>> ||        }||
>>>>>>>> ||    }||
>>>>>>>> ||}||
>>>>>>>> ||=========================||
>>>>>>>> | |
>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second "java 
>>>>>>>> -cp .
>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>> |
>>>>>>> |I saw crash with the latest 6 update release with both test cases.
>>>>>>> The crash seems to be at the same spot.
>>>>>>> |
>>>>>>>> |||
>>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior (not
>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>> checking),
>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>> |
>>>>>>> |I checked the jdk 6 code and those 3 methods which I changed look
>>>>>>> the
>>>>>>> same as jdk 8.
>>>>>>> Sure, I can add a jtreg test.
>>>>>>> |
>>>>>>>> |||
>>>>>>>> ||Thanks||
>>>>>>>> ||- Ioi||
>>>>>>>> ||
>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>> |
>>>>>>>>> |Hi Calvin, ||
>>>>>>>>> | |
>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>>> declared with a last parameter of TRAPS and called with a CHECK_
>>>>>>>>> macro. The way this code is written it does not seem to expect 
>>>>>>>>> any
>>>>>>>>> exceptions to be possible. I would check with Karen on this. ||
>>>>>>>>> |
>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>> changes.
>>>>>>> I can give it a try.
>>>>>>> |
>>>>>>>>> || |
>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>> | |
>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>> |
>>>>>>> |It is required for the THROW_MSG().
>>>>>>> It won't be needed if the method is declared with TRAPS as the last
>>>>>>> parameter (I think).
>>>>>>>
>>>>>>> thanks,
>>>>>>> Calvin
>>>>>>> |
>>>>>>>>> || |
>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>> throwing
>>>>>>>>> exceptions - don't know what the thought process was there :) ||
>>>>>>>>> | |
>>>>>>>>> ||David ||
>>>>>>>>> | |
>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>> |
>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>> similar
>>>>>>>>>> crash ||
>>>>>>>>>> ||by trying to load a class from an empty jar which is in the ||
>>>>>>>>>> ||bootclasspath. The following program can trigger the crash if
>>>>>>>>>> the ||
>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>> | |
>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>> ||         try { ||
>>>>>>>>>> ||             Class cls =
>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>> cls.getName()); ||
>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>> ||         } ||
>>>>>>>>>> ||     } ||
>>>>>>>>>> ||} ||
>>>>>>>>>> | |
>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>>>>>>> above test ||
>>>>>>>>>> ||scenario. ||
>>>>>>>>>> | |
>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>> thrown ||
>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>> ||java.lang.ClassNotFoundException: javax.crypto.KeyGenerator ||
>>>>>>>>>> ||         at
>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>> ||         at
>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>> ||         at java.security.AccessController.doPrivileged(Native
>>>>>>>>>> Method) ||
>>>>>>>>>> ||         at
>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>>> ||         at
>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>> ||         at
>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) ||
>>>>>>>>>> ||         at
>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>> | |
>>>>>>>>>> ||webrev: http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>> | |
>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>> | |
>>>>>>>>>> ||Tests: ||
>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>> | |
>>>>>>>>>> ||thanks, ||
>>>>>>>>>> ||Calvin ||
>>>>>>>>>> | |
>>>>>>>>>> | |
>>>>>>>>>> |
>>>>>>>> |
>>>>>>>> |
>>>>>>>
>>>>>>
>>>>
>>>
>>


From thomas.schatzl at oracle.com  Tue Aug 13 03:47:51 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 13 Aug 2013 12:47:51 +0200
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
Message-ID: <1376390871.2693.23.camel@cirrus>

Hi,

On Fri, 2013-08-09 at 07:57 -0700, Harold Seigel wrote:
> Hi,
> 
> Please review this latest version of the bug fix for 8003424:
> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/

Some comments after briefly looking over the changes:

- in Universe::reserve_heap() at the beginning there is a now obsolete
comment about rounding class space size up due to being below the heap.

Thomas




From staffan.larsen at oracle.com  Tue Aug 13 03:57:14 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 13 Aug 2013 12:57:14 +0200
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <00a301ce97e4$7b2fc930$718f5b90$@oracle.com>
References: <52081FF6.4040205@oracle.com>
	<5208790D.9010309@oracle.com>	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>	<520914A1.8050905@oracle.com>
	<52095712.4080404@oracle.com>
	<033D0E0C-963F-4272-ABF1-028F4935F4C9@oracle.com>
	<00a301ce97e4$7b2fc930$718f5b90$@oracle.com>
Message-ID: <5A25CD50-5BE7-484C-9C65-F7DF7095CAA2@oracle.com>

I agree with those skeptical to this change. The correct approach here is to make sure we get core files when crashes occur and then process that core with SA. And I agree that SA needs to be stabilized and could use a lot more testing.

/Staffan

On 13 aug 2013, at 07:17, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:

> Hi Chris,
> 
>> The SA logic would be exercised during our internal testing and could be
> fixed before the release.  Right now the situation is we see a >customer
> crash, we want to run the SA and notice that it's broken.  That's too late.
> 
> This is an issue with our current testing of the SA. This should be
> addressed by making sure our test works and covers the functionality of the
> SA, not by making the JVM dependent on the SA.
> 
> Thanks,
> Christian
> 
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net
> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Christian
> Thalinger
> Sent: Monday, August 12, 2013 9:12 PM
> To: Coleen Phillimore
> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net;
> 'hotspot compiler'; hotspot-runtime-dev at openjdk.java.net; 'David Holmes'
> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
> 
> 
> On Aug 12, 2013, at 2:43 PM, Coleen Phillimore
> <coleen.phillimore at oracle.com> wrote:
> 
>> 
>> Yumin,
>> 
>> I don't think this change should be added to the JVM for the following
> reasons.
> 
> This change is something that I (kind of) requested from Yumin since it
> would help to reproduce crashes in the compilers.  Getting replay data after
> the fact can be very tricky (given all the system library interactions or a
> broken SA; see below).
> 
>> 
>> 1. Error handling should only contain safe actions.   We have concerns
> that the SA is not that stable
> 
> .which is a problem, I agree.  To make it more stable we need to use it so
> we can detect problems early.  
> 
> Having the SA dump data when we crash in the compiler can be one of these
> usages.  The SA logic would be exercised during our internal testing and
> could be fixed before the release.  Right now the situation is we see a
> customer crash, we want to run the SA and notice that it's broken.  That's
> too late.
> 
>> and would prevent getting a real core file in many error situations.   You
> couldn't have tested all error situations because these are usually the
> things we don't know about.   You also mention that there are currently bugs
> preventing this feature from working in your first email.
>> 
>> 2. I am not convinced that having a separate jar file with loaded classes
> (is it a list that SA generates?) would be collected by an error reporter.
> If it's collected, I don't see how helpful it would be.
> 
> As mentioned above, it's required to replay compilations.
> 
>> Also a customer may not want their classes disclosed in error reporting.
> 
> They don't have to if they don't want to.
> 
> -- Chris
> 
>> 
>> 3.  This doesn't seem important enough to include as a new feature in jdk8
> release, which is feature-complete.   I don't see a customer request for it.
>> 
>> Coleen
>> 
>> On 08/12/2013 01:00 PM, Yumin Qi wrote:
>>> Chris, David
>>> 
>>> Yes. This can be after crash with core file, but some time no core file
> generated (also if the error could not repeat, we will never got information
> again), so dumping  target process is also a choice. To avoid more
> confusion, this step was launched at the very last moment, just before raise
> abort to exit. At this moment, if client process could not attach to the
> target process it will exit right away.
>>> 
>>> Answers to David:
>>> 
>>> Note that the SA is only present in a full JDK, not a JRE (full or
> compact profile).
>>> Yes, in code, if no sa-jdi.jar found, skip fork.
>>> 
>>> - What mechanism will the SA try to use to query the VM?
>>> 
>>> After successfully attached to target process, SA will read via proc
> APIs and vmStructs (named TYPEDB) to iterate  memory of system dictionary
> read (only)  from target process to dump class information.
>>> 
>>> - What if the state of the crashed VM stops the SA from being able to
> attach properly (ie both processes hang)?
>>> 
>>> That should be an attaching API problem. We haven't watched such case
> happened so far.
>>> 
>>> - What if it the SA also crashes, will it launch a third VM then a fourth
> etc?
>>> 
>>> Definitely don't want to see this happened in a chain. The solution 
>>> may use a property such as 
>>> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into 
>>> SA process, at launching call, check if the property set, if set, do 
>>> not fork. When SA process died, it will generate core file first, 
>>> note the target process still waiting for its exit, so when target 
>>> exit, the core file (if both use default core as name) will be 
>>> override by target. The SA process will only leave a hs_err_pid*.log 
>>> file. (? read such property in handler is possible?)
>>> 
>>> Also what is the nature of this dump? How big is it? Where will it go?
>>> The jars includes *app.jar and *boot.jar, the later usually can be
> ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent. The
> app.jar will contain all classes by customer, so we can do whatever we can
> to the jar.
>>> 
>>> 
>>> Thanks
>>> Yumin
>>> 
>>> 
>>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>>>> Hi Yumin,
>>>> 
>>>> The idea is to do as little as possible in the VM error handler, since
> we've crashed for some reason we don't know what state the process is in and
> we have to be extremely careful in when we're gathering the information.
> This seems like a step that is risky for all of the reasons David mentioned
> below.
>>>> 
>>>> It's also information that can easily be extracted post-mortem from the
> core/mdmp using the method you described for OSX, so gathering this at the
> time of a crash seems like an unnecessary risk.
>>>> 
>>>> Thanks,
>>>> Christian
>>>> 
>>>> -----Original Message-----
>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net 
>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of 
>>>> David Holmes
>>>> Sent: Monday, August 12, 2013 1:56 AM
>>>> To: Yumin Qi
>>>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>>> 
>>>> Hi Yumin,
>>>> 
>>>> Note that the SA is only present in a full JDK, not a JRE (full or
> compact profile).
>>>> 
>>>> I have quite a few concerns with this:
>>>> 
>>>> We already do a lot of things that are not valid to be done from a 
>>>> signal handling context but this really takes that to an extreme. 
>>>> Doing fork-exec from a signal handler seems like a recipe for 
>>>> disaster (Note the existing onError facility is typically used for 
>>>> synchronous failures.)
>>>> 
>>>> The idea of launching a second VM to try and query a VM that has crashed
> also seems somewhat problematic:
>>>> - What mechanism will the SA try to use to query the VM?
>>>> - What if the state of the crashed VM stops the SA from being able to
> attach properly (ie both processes hang)?
>>>> - What if it the SA also crashes, will it launch a third VM then a
> fourth etc?
>>>> 
>>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>>>> Hi, all
>>>>> 
>>>>>   I would like to have your review for
>>>>> 
>>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>>> 
>>>>> Description: When JVM crashed, we also want to check the 
>>>>> application class files especially we got core file from customers.  
>>>>> The aftermath analysis will benefit from all loaded java classes 
>>>>> available. In this change, spawn another process running SA to do 
>>>>> the job when JVM crashes, this way also avoid further messing up 
>>>>> with the error report which already in signal handler.
>>>>> 
>>>>> Note: The test has done with following two bugs worked around:
>>>>>   8022655: ClassDump ignored jarStream setting (This will be fixed 
>>>>> and integrated by Kevin Walls soon)
>>>>>   8011888: sa.js: TypeError: [object JSAdapter] has no such 
>>>>> function "__has__" (Not know when it will be integrated)
>>>>>   That is, without those two fixed, the jars of loaded classes 
>>>>> will not be successfully dumped.
>>>>>   Also, on MacOS it requires security access permission to attach 
>>>>> to another process, so omit doing so. To get loaded jar file s, 
>>>>> with core file available (on all platforms), one can (only after 
>>>>> this
>>>>> change) do
>>>>> 
>>>>>   $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar 
>>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>>> 
>>>>> 
>>>>> Thanks
>>>>> Yumin
>>> 
>> 
> 
> 


From thomas.schatzl at oracle.com  Tue Aug 13 05:47:53 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 13 Aug 2013 14:47:53 +0200
Subject: RFR (XXS): 8022784 TaskQueue misses minimal documentation and
	references for analysis
In-Reply-To: <5208CC05.5030508@oracle.com>
References: <1376297621.11034.4.camel@cirrus> <5208CC05.5030508@oracle.com>
Message-ID: <1376398073.2693.26.camel@cirrus>

On Mon, 2013-08-12 at 21:50 +1000, David Holmes wrote:
> Okay.
> 

Thanks,
  Thomas



From yumin.qi at oracle.com  Tue Aug 13 09:04:28 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 13 Aug 2013 09:04:28 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <5A25CD50-5BE7-484C-9C65-F7DF7095CAA2@oracle.com>
References: <52081FF6.4040205@oracle.com>
	<5208790D.9010309@oracle.com>	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>	<520914A1.8050905@oracle.com>
	<52095712.4080404@oracle.com>
	<033D0E0C-963F-4272-ABF1-028F4935F4C9@oracle.com>
	<00a301ce97e4$7b2fc930$718f5b90$@oracle.com>
	<5A25CD50-5BE7-484C-9C65-F7DF7095CAA2@oracle.com>
Message-ID: <520A590C.6000901@oracle.com>

To summarize the discussion of this change:

1) Launching SA process at the last stage of error handling caused much 
concern;
2) SA is not stable and need stabilization in future enhancement, which 
looks like a long term task;
3) With SA and available core file, we can get jar files for aftermath 
analysis but you need to become familiar with SA;

So I will closed this bug as 'no fix'.
BTW, when working on this bug, filed other two bugs which should be 
fixed to dump classes.

Thanks for the inputs from all of you.

Yumin

On 8/13/2013 3:57 AM, Staffan Larsen wrote:
> I agree with those skeptical to this change. The correct approach here is to make sure we get core files when crashes occur and then process that core with SA. And I agree that SA needs to be stabilized and could use a lot more testing.
>
> /Staffan
>
> On 13 aug 2013, at 07:17, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:
>
>> Hi Chris,
>>
>>> The SA logic would be exercised during our internal testing and could be
>> fixed before the release.  Right now the situation is we see a >customer
>> crash, we want to run the SA and notice that it's broken.  That's too late.
>>
>> This is an issue with our current testing of the SA. This should be
>> addressed by making sure our test works and covers the functionality of the
>> SA, not by making the JVM dependent on the SA.
>>
>> Thanks,
>> Christian
>>
>> -----Original Message-----
>> From: hotspot-runtime-dev-bounces at openjdk.java.net
>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Christian
>> Thalinger
>> Sent: Monday, August 12, 2013 9:12 PM
>> To: Coleen Phillimore
>> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net;
>> 'hotspot compiler'; hotspot-runtime-dev at openjdk.java.net; 'David Holmes'
>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>
>>
>> On Aug 12, 2013, at 2:43 PM, Coleen Phillimore
>> <coleen.phillimore at oracle.com> wrote:
>>
>>> Yumin,
>>>
>>> I don't think this change should be added to the JVM for the following
>> reasons.
>>
>> This change is something that I (kind of) requested from Yumin since it
>> would help to reproduce crashes in the compilers.  Getting replay data after
>> the fact can be very tricky (given all the system library interactions or a
>> broken SA; see below).
>>
>>> 1. Error handling should only contain safe actions.   We have concerns
>> that the SA is not that stable
>>
>> .which is a problem, I agree.  To make it more stable we need to use it so
>> we can detect problems early.
>>
>> Having the SA dump data when we crash in the compiler can be one of these
>> usages.  The SA logic would be exercised during our internal testing and
>> could be fixed before the release.  Right now the situation is we see a
>> customer crash, we want to run the SA and notice that it's broken.  That's
>> too late.
>>
>>> and would prevent getting a real core file in many error situations.   You
>> couldn't have tested all error situations because these are usually the
>> things we don't know about.   You also mention that there are currently bugs
>> preventing this feature from working in your first email.
>>> 2. I am not convinced that having a separate jar file with loaded classes
>> (is it a list that SA generates?) would be collected by an error reporter.
>> If it's collected, I don't see how helpful it would be.
>>
>> As mentioned above, it's required to replay compilations.
>>
>>> Also a customer may not want their classes disclosed in error reporting.
>> They don't have to if they don't want to.
>>
>> -- Chris
>>
>>> 3.  This doesn't seem important enough to include as a new feature in jdk8
>> release, which is feature-complete.   I don't see a customer request for it.
>>> Coleen
>>>
>>> On 08/12/2013 01:00 PM, Yumin Qi wrote:
>>>> Chris, David
>>>>
>>>> Yes. This can be after crash with core file, but some time no core file
>> generated (also if the error could not repeat, we will never got information
>> again), so dumping  target process is also a choice. To avoid more
>> confusion, this step was launched at the very last moment, just before raise
>> abort to exit. At this moment, if client process could not attach to the
>> target process it will exit right away.
>>>> Answers to David:
>>>>
>>>> Note that the SA is only present in a full JDK, not a JRE (full or
>> compact profile).
>>>> Yes, in code, if no sa-jdi.jar found, skip fork.
>>>>
>>>> - What mechanism will the SA try to use to query the VM?
>>>>
>>>> After successfully attached to target process, SA will read via proc
>> APIs and vmStructs (named TYPEDB) to iterate  memory of system dictionary
>> read (only)  from target process to dump class information.
>>>> - What if the state of the crashed VM stops the SA from being able to
>> attach properly (ie both processes hang)?
>>>> That should be an attaching API problem. We haven't watched such case
>> happened so far.
>>>> - What if it the SA also crashes, will it launch a third VM then a fourth
>> etc?
>>>> Definitely don't want to see this happened in a chain. The solution
>>>> may use a property such as
>>>> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into
>>>> SA process, at launching call, check if the property set, if set, do
>>>> not fork. When SA process died, it will generate core file first,
>>>> note the target process still waiting for its exit, so when target
>>>> exit, the core file (if both use default core as name) will be
>>>> override by target. The SA process will only leave a hs_err_pid*.log
>>>> file. (? read such property in handler is possible?)
>>>>
>>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>> The jars includes *app.jar and *boot.jar, the later usually can be
>> ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent. The
>> app.jar will contain all classes by customer, so we can do whatever we can
>> to the jar.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>>>>> Hi Yumin,
>>>>>
>>>>> The idea is to do as little as possible in the VM error handler, since
>> we've crashed for some reason we don't know what state the process is in and
>> we have to be extremely careful in when we're gathering the information.
>> This seems like a step that is risky for all of the reasons David mentioned
>> below.
>>>>> It's also information that can easily be extracted post-mortem from the
>> core/mdmp using the method you described for OSX, so gathering this at the
>> time of a crash seems like an unnecessary risk.
>>>>> Thanks,
>>>>> Christian
>>>>>
>>>>> -----Original Message-----
>>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
>>>>> David Holmes
>>>>> Sent: Monday, August 12, 2013 1:56 AM
>>>>> To: Yumin Qi
>>>>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>>>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>>>>
>>>>> Hi Yumin,
>>>>>
>>>>> Note that the SA is only present in a full JDK, not a JRE (full or
>> compact profile).
>>>>> I have quite a few concerns with this:
>>>>>
>>>>> We already do a lot of things that are not valid to be done from a
>>>>> signal handling context but this really takes that to an extreme.
>>>>> Doing fork-exec from a signal handler seems like a recipe for
>>>>> disaster (Note the existing onError facility is typically used for
>>>>> synchronous failures.)
>>>>>
>>>>> The idea of launching a second VM to try and query a VM that has crashed
>> also seems somewhat problematic:
>>>>> - What mechanism will the SA try to use to query the VM?
>>>>> - What if the state of the crashed VM stops the SA from being able to
>> attach properly (ie both processes hang)?
>>>>> - What if it the SA also crashes, will it launch a third VM then a
>> fourth etc?
>>>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>>>>> Hi, all
>>>>>>
>>>>>>    I would like to have your review for
>>>>>>
>>>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>>>>
>>>>>> Description: When JVM crashed, we also want to check the
>>>>>> application class files especially we got core file from customers.
>>>>>> The aftermath analysis will benefit from all loaded java classes
>>>>>> available. In this change, spawn another process running SA to do
>>>>>> the job when JVM crashes, this way also avoid further messing up
>>>>>> with the error report which already in signal handler.
>>>>>>
>>>>>> Note: The test has done with following two bugs worked around:
>>>>>>    8022655: ClassDump ignored jarStream setting (This will be fixed
>>>>>> and integrated by Kevin Walls soon)
>>>>>>    8011888: sa.js: TypeError: [object JSAdapter] has no such
>>>>>> function "__has__" (Not know when it will be integrated)
>>>>>>    That is, without those two fixed, the jars of loaded classes
>>>>>> will not be successfully dumped.
>>>>>>    Also, on MacOS it requires security access permission to attach
>>>>>> to another process, so omit doing so. To get loaded jar file s,
>>>>>> with core file available (on all platforms), one can (only after
>>>>>> this
>>>>>> change) do
>>>>>>
>>>>>>    $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
>>>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>


From christian.thalinger at oracle.com  Tue Aug 13 10:17:33 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 13 Aug 2013 10:17:33 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <00a301ce97e4$7b2fc930$718f5b90$@oracle.com>
References: <52081FF6.4040205@oracle.com>
	<5208790D.9010309@oracle.com>	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>	<520914A1.8050905@oracle.com>
	<52095712.4080404@oracle.com>
	<033D0E0C-963F-4272-ABF1-028F4935F4C9@oracle.com>
	<00a301ce97e4$7b2fc930$718f5b90$@oracle.com>
Message-ID: <04F964CD-1133-4C6D-9B17-184B43133E9C@oracle.com>


On Aug 12, 2013, at 10:17 PM, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:

> Hi Chris,
> 
>> The SA logic would be exercised during our internal testing and could be
> fixed before the release.  Right now the situation is we see a >customer
> crash, we want to run the SA and notice that it's broken.  That's too late.
> 
> This is an issue with our current testing of the SA. This should be
> addressed by making sure our test works and covers the functionality of the
> SA

I hope someone is doing this?

-- Chris

> , not by making the JVM dependent on the SA.
> 
> Thanks,
> Christian
> 
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net
> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Christian
> Thalinger
> Sent: Monday, August 12, 2013 9:12 PM
> To: Coleen Phillimore
> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net;
> 'hotspot compiler'; hotspot-runtime-dev at openjdk.java.net; 'David Holmes'
> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
> 
> 
> On Aug 12, 2013, at 2:43 PM, Coleen Phillimore
> <coleen.phillimore at oracle.com> wrote:
> 
>> 
>> Yumin,
>> 
>> I don't think this change should be added to the JVM for the following
> reasons.
> 
> This change is something that I (kind of) requested from Yumin since it
> would help to reproduce crashes in the compilers.  Getting replay data after
> the fact can be very tricky (given all the system library interactions or a
> broken SA; see below).
> 
>> 
>> 1. Error handling should only contain safe actions.   We have concerns
> that the SA is not that stable
> 
> .which is a problem, I agree.  To make it more stable we need to use it so
> we can detect problems early.  
> 
> Having the SA dump data when we crash in the compiler can be one of these
> usages.  The SA logic would be exercised during our internal testing and
> could be fixed before the release.  Right now the situation is we see a
> customer crash, we want to run the SA and notice that it's broken.  That's
> too late.
> 
>> and would prevent getting a real core file in many error situations.   You
> couldn't have tested all error situations because these are usually the
> things we don't know about.   You also mention that there are currently bugs
> preventing this feature from working in your first email.
>> 
>> 2. I am not convinced that having a separate jar file with loaded classes
> (is it a list that SA generates?) would be collected by an error reporter.
> If it's collected, I don't see how helpful it would be.
> 
> As mentioned above, it's required to replay compilations.
> 
>> Also a customer may not want their classes disclosed in error reporting.
> 
> They don't have to if they don't want to.
> 
> -- Chris
> 
>> 
>> 3.  This doesn't seem important enough to include as a new feature in jdk8
> release, which is feature-complete.   I don't see a customer request for it.
>> 
>> Coleen
>> 
>> On 08/12/2013 01:00 PM, Yumin Qi wrote:
>>> Chris, David
>>> 
>>> Yes. This can be after crash with core file, but some time no core file
> generated (also if the error could not repeat, we will never got information
> again), so dumping  target process is also a choice. To avoid more
> confusion, this step was launched at the very last moment, just before raise
> abort to exit. At this moment, if client process could not attach to the
> target process it will exit right away.
>>> 
>>> Answers to David:
>>> 
>>> Note that the SA is only present in a full JDK, not a JRE (full or
> compact profile).
>>> Yes, in code, if no sa-jdi.jar found, skip fork.
>>> 
>>> - What mechanism will the SA try to use to query the VM?
>>> 
>>> After successfully attached to target process, SA will read via proc
> APIs and vmStructs (named TYPEDB) to iterate  memory of system dictionary
> read (only)  from target process to dump class information.
>>> 
>>> - What if the state of the crashed VM stops the SA from being able to
> attach properly (ie both processes hang)?
>>> 
>>> That should be an attaching API problem. We haven't watched such case
> happened so far.
>>> 
>>> - What if it the SA also crashes, will it launch a third VM then a fourth
> etc?
>>> 
>>> Definitely don't want to see this happened in a chain. The solution 
>>> may use a property such as 
>>> sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into 
>>> SA process, at launching call, check if the property set, if set, do 
>>> not fork. When SA process died, it will generate core file first, 
>>> note the target process still waiting for its exit, so when target 
>>> exit, the core file (if both use default core as name) will be 
>>> override by target. The SA process will only leave a hs_err_pid*.log 
>>> file. (? read such property in handler is possible?)
>>> 
>>> Also what is the nature of this dump? How big is it? Where will it go?
>>> The jars includes *app.jar and *boot.jar, the later usually can be
> ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent. The
> app.jar will contain all classes by customer, so we can do whatever we can
> to the jar.
>>> 
>>> 
>>> Thanks
>>> Yumin
>>> 
>>> 
>>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>>>> Hi Yumin,
>>>> 
>>>> The idea is to do as little as possible in the VM error handler, since
> we've crashed for some reason we don't know what state the process is in and
> we have to be extremely careful in when we're gathering the information.
> This seems like a step that is risky for all of the reasons David mentioned
> below.
>>>> 
>>>> It's also information that can easily be extracted post-mortem from the
> core/mdmp using the method you described for OSX, so gathering this at the
> time of a crash seems like an unnecessary risk.
>>>> 
>>>> Thanks,
>>>> Christian
>>>> 
>>>> -----Original Message-----
>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net 
>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of 
>>>> David Holmes
>>>> Sent: Monday, August 12, 2013 1:56 AM
>>>> To: Yumin Qi
>>>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>>> 
>>>> Hi Yumin,
>>>> 
>>>> Note that the SA is only present in a full JDK, not a JRE (full or
> compact profile).
>>>> 
>>>> I have quite a few concerns with this:
>>>> 
>>>> We already do a lot of things that are not valid to be done from a 
>>>> signal handling context but this really takes that to an extreme. 
>>>> Doing fork-exec from a signal handler seems like a recipe for 
>>>> disaster (Note the existing onError facility is typically used for 
>>>> synchronous failures.)
>>>> 
>>>> The idea of launching a second VM to try and query a VM that has crashed
> also seems somewhat problematic:
>>>> - What mechanism will the SA try to use to query the VM?
>>>> - What if the state of the crashed VM stops the SA from being able to
> attach properly (ie both processes hang)?
>>>> - What if it the SA also crashes, will it launch a third VM then a
> fourth etc?
>>>> 
>>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>>>> Hi, all
>>>>> 
>>>>>   I would like to have your review for
>>>>> 
>>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>>> 
>>>>> Description: When JVM crashed, we also want to check the 
>>>>> application class files especially we got core file from customers.  
>>>>> The aftermath analysis will benefit from all loaded java classes 
>>>>> available. In this change, spawn another process running SA to do 
>>>>> the job when JVM crashes, this way also avoid further messing up 
>>>>> with the error report which already in signal handler.
>>>>> 
>>>>> Note: The test has done with following two bugs worked around:
>>>>>   8022655: ClassDump ignored jarStream setting (This will be fixed 
>>>>> and integrated by Kevin Walls soon)
>>>>>   8011888: sa.js: TypeError: [object JSAdapter] has no such 
>>>>> function "__has__" (Not know when it will be integrated)
>>>>>   That is, without those two fixed, the jars of loaded classes 
>>>>> will not be successfully dumped.
>>>>>   Also, on MacOS it requires security access permission to attach 
>>>>> to another process, so omit doing so. To get loaded jar file s, 
>>>>> with core file available (on all platforms), one can (only after 
>>>>> this
>>>>> change) do
>>>>> 
>>>>>   $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar 
>>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>>> 
>>>>> 
>>>>> Thanks
>>>>> Yumin
>>> 
>> 
> 
> 


From christian.thalinger at oracle.com  Tue Aug 13 10:18:39 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 13 Aug 2013 10:18:39 -0700
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <5209AB7A.8090503@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com> <52095712.4080404@oracle.com>
	<5209AB7A.8090503@oracle.com>
Message-ID: <332BD6B0-650E-4C10-BCD6-443701DA1F79@oracle.com>


On Aug 12, 2013, at 8:43 PM, Yumin Qi <yumin.qi at oracle.com> wrote:

> Coleen,
> 
>  Chris Thalinger  already answered some of your concerns. For jar file which dumped in this change, compiler replay has added functions to SA to dump out replay jars against core file. Since customer is the one wants us to fix problems in VM, the disclosure of such jar to us should be OK I think, any way if we have core file, we already have the loaded classes.
>  This should mainly be focused on dump jars as possible at the last stage of error reporter. I chose using SA since with c++ to implement same functionality I have to use zip file operation to do so, which is not a fit at such condition, but in SA the same operation ready for use. The only case we could not get jar files is no core file available, in such case, this change will supply an alternate.
> 
>  Looks this need more discussion for further decision.

One more comment (just FTR):  the class dumping should only happen when we crash in one of the compiler threads; not always.

-- Chris

> 
> Thanks
> Yumin
> 
> 
> On 8/12/2013 2:43 PM, Coleen Phillimore wrote:
>> 
>> Yumin,
>> 
>> I don't think this change should be added to the JVM for the following reasons.
>> 
>> 1. Error handling should only contain safe actions.   We have concerns that the SA is not that stable and would prevent getting a real core file in many error situations.   You couldn't have tested all error situations because these are usually the things we don't know about.   You also mention that there are currently bugs preventing this feature from working in your first email.
>> 
>> 2. I am not convinced that having a separate jar file with loaded classes (is it a list that SA generates?) would be collected by an error reporter.   If it's collected, I don't see how helpful it would be.  Also a customer may not want their classes disclosed in error reporting.
>> 
>> 3.  This doesn't seem important enough to include as a new feature in jdk8 release, which is feature-complete.   I don't see a customer request for it.
>> 
>> Coleen
>> 
>> On 08/12/2013 01:00 PM, Yumin Qi wrote:
>>> Chris, David
>>> 
>>>  Yes. This can be after crash with core file, but some time no core file generated (also if the error could not repeat, we will never got information again), so dumping  target process is also a choice. To avoid more confusion, this step was launched at the very last moment, just before raise abort to exit. At this moment, if client process could not attach to the target process it will exit right away.
>>> 
>>> Answers to David:
>>> 
>>> Note that the SA is only present in a full JDK, not a JRE (full or compact profile).
>>>  Yes, in code, if no sa-jdi.jar found, skip fork.
>>> 
>>> - What mechanism will the SA try to use to query the VM?
>>> 
>>>  After successfully attached to target process, SA will read via proc APIs and vmStructs (named TYPEDB) to iterate  memory of system dictionary read (only)  from target process to dump class information.
>>> 
>>> - What if the state of the crashed VM stops the SA from being able to attach properly (ie both processes hang)?
>>> 
>>>  That should be an attaching API problem. We haven't watched such case happened so far.
>>> 
>>> - What if it the SA also crashes, will it launch a third VM then a fourth etc?
>>> 
>>>  Definitely don't want to see this happened in a chain. The solution may use a property such as sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into SA process, at launching call, check if the property set, if set, do not fork. When SA process died, it will generate core file first, note the target process still waiting for its exit, so when target exit, the core file (if both use default core as name) will be override by target. The SA process will only leave a hs_err_pid*.log file. (? read such property in handler is possible?)
>>> 
>>> Also what is the nature of this dump? How big is it? Where will it go?
>>> The jars includes *app.jar and *boot.jar, the later usually can be ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent. The app.jar will contain all classes by customer, so we can do whatever we can to the jar.
>>> 
>>> 
>>> Thanks
>>> Yumin
>>> 
>>> 
>>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>>>> Hi Yumin,
>>>> 
>>>> The idea is to do as little as possible in the VM error handler, since we've crashed for some reason we don't know what state the process is in and we have to be extremely careful in when we're gathering the information. This seems like a step that is risky for all of the reasons David mentioned below.
>>>> 
>>>> It's also information that can easily be extracted post-mortem from the core/mdmp using the method you described for OSX, so gathering this at the time of a crash seems like an unnecessary risk.
>>>> 
>>>> Thanks,
>>>> Christian
>>>> 
>>>> -----Original Message-----
>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
>>>> Sent: Monday, August 12, 2013 1:56 AM
>>>> To: Yumin Qi
>>>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>>> 
>>>> Hi Yumin,
>>>> 
>>>> Note that the SA is only present in a full JDK, not a JRE (full or compact profile).
>>>> 
>>>> I have quite a few concerns with this:
>>>> 
>>>> We already do a lot of things that are not valid to be done from a signal handling context but this really takes that to an extreme. Doing fork-exec from a signal handler seems like a recipe for disaster (Note the existing onError facility is typically used for synchronous failures.)
>>>> 
>>>> The idea of launching a second VM to try and query a VM that has crashed also seems somewhat problematic:
>>>> - What mechanism will the SA try to use to query the VM?
>>>> - What if the state of the crashed VM stops the SA from being able to attach properly (ie both processes hang)?
>>>> - What if it the SA also crashes, will it launch a third VM then a fourth etc?
>>>> 
>>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>>>> Hi, all
>>>>> 
>>>>>    I would like to have your review for
>>>>> 
>>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>>> 
>>>>> Description: When JVM crashed, we also want to check the application
>>>>> class files especially we got core file from customers.  The aftermath
>>>>> analysis will benefit from all loaded java classes available. In this
>>>>> change, spawn another process running SA to do the job when JVM
>>>>> crashes, this way also avoid further messing up with the error report
>>>>> which already in signal handler.
>>>>> 
>>>>> Note: The test has done with following two bugs worked around:
>>>>>    8022655: ClassDump ignored jarStream setting (This will be fixed
>>>>> and integrated by Kevin Walls soon)
>>>>>    8011888: sa.js: TypeError: [object JSAdapter] has no such function
>>>>> "__has__" (Not know when it will be integrated)
>>>>>    That is, without those two fixed, the jars of loaded classes will
>>>>> not be successfully dumped.
>>>>>    Also, on MacOS it requires security access permission to attach to
>>>>> another process, so omit doing so. To get loaded jar file s, with core
>>>>> file available (on all platforms), one can (only after this
>>>>> change) do
>>>>> 
>>>>>    $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
>>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>>> 
>>>>> 
>>>>> Thanks
>>>>> Yumin
>>> 
>> 
> 


From harold.seigel at oracle.com  Tue Aug 13 10:24:33 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Tue, 13 Aug 2013 13:24:33 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <1376390871.2693.23.camel@cirrus>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
	<1376390871.2693.23.camel@cirrus>
Message-ID: <520A6BD1.2030503@oracle.com>

Hi Thomas,

Thanks!  I removed the obsolete comment.

Harold

On 8/13/2013 6:47 AM, Thomas Schatzl wrote:
> Hi,
>
> On Fri, 2013-08-09 at 07:57 -0700, Harold Seigel wrote:
>> Hi,
>>
>> Please review this latest version of the bug fix for 8003424:
>> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/
> Some comments after briefly looking over the changes:
>
> - in Universe::reserve_heap() at the beginning there is a now obsolete
> comment about rounding class space size up due to being below the heap.
>
> Thomas
>
>
>


From coleen.phillimore at oracle.com  Tue Aug 13 10:41:47 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 13 Aug 2013 13:41:47 -0400
Subject: RFR: 8020962: dump loaded java classes when vm crash
In-Reply-To: <332BD6B0-650E-4C10-BCD6-443701DA1F79@oracle.com>
References: <52081FF6.4040205@oracle.com> <5208790D.9010309@oracle.com>
	<00cc01ce975a$a3ea86b0$ebbf9410$@oracle.com>
	<520914A1.8050905@oracle.com> <52095712.4080404@oracle.com>
	<5209AB7A.8090503@oracle.com>
	<332BD6B0-650E-4C10-BCD6-443701DA1F79@oracle.com>
Message-ID: <520A6FDB.6050609@oracle.com>


On 08/13/2013 01:18 PM, Christian Thalinger wrote:
> On Aug 12, 2013, at 8:43 PM, Yumin Qi <yumin.qi at oracle.com> wrote:
>
>> Coleen,
>>
>>   Chris Thalinger  already answered some of your concerns. For jar file which dumped in this change, compiler replay has added functions to SA to dump out replay jars against core file. Since customer is the one wants us to fix problems in VM, the disclosure of such jar to us should be OK I think, any way if we have core file, we already have the loaded classes.
>>   This should mainly be focused on dump jars as possible at the last stage of error reporter. I chose using SA since with c++ to implement same functionality I have to use zip file operation to do so, which is not a fit at such condition, but in SA the same operation ready for use. The only case we could not get jar files is no core file available, in such case, this change will supply an alternate.
>>
>>   Looks this need more discussion for further decision.
> One more comment (just FTR):  the class dumping should only happen when we crash in one of the compiler threads; not always.

Do we have a running list of SA requirements that we can add this to the 
list?

thanks,
Coleen

>
> -- Chris
>
>> Thanks
>> Yumin
>>
>>
>> On 8/12/2013 2:43 PM, Coleen Phillimore wrote:
>>> Yumin,
>>>
>>> I don't think this change should be added to the JVM for the following reasons.
>>>
>>> 1. Error handling should only contain safe actions.   We have concerns that the SA is not that stable and would prevent getting a real core file in many error situations.   You couldn't have tested all error situations because these are usually the things we don't know about.   You also mention that there are currently bugs preventing this feature from working in your first email.
>>>
>>> 2. I am not convinced that having a separate jar file with loaded classes (is it a list that SA generates?) would be collected by an error reporter.   If it's collected, I don't see how helpful it would be.  Also a customer may not want their classes disclosed in error reporting.
>>>
>>> 3.  This doesn't seem important enough to include as a new feature in jdk8 release, which is feature-complete.   I don't see a customer request for it.
>>>
>>> Coleen
>>>
>>> On 08/12/2013 01:00 PM, Yumin Qi wrote:
>>>> Chris, David
>>>>
>>>>   Yes. This can be after crash with core file, but some time no core file generated (also if the error could not repeat, we will never got information again), so dumping  target process is also a choice. To avoid more confusion, this step was launched at the very last moment, just before raise abort to exit. At this moment, if client process could not attach to the target process it will exit right away.
>>>>
>>>> Answers to David:
>>>>
>>>> Note that the SA is only present in a full JDK, not a JRE (full or compact profile).
>>>>   Yes, in code, if no sa-jdi.jar found, skip fork.
>>>>
>>>> - What mechanism will the SA try to use to query the VM?
>>>>
>>>>   After successfully attached to target process, SA will read via proc APIs and vmStructs (named TYPEDB) to iterate  memory of system dictionary read (only)  from target process to dump class information.
>>>>
>>>> - What if the state of the crashed VM stops the SA from being able to attach properly (ie both processes hang)?
>>>>
>>>>   That should be an attaching API problem. We haven't watched such case happened so far.
>>>>
>>>> - What if it the SA also crashes, will it launch a third VM then a fourth etc?
>>>>
>>>>   Definitely don't want to see this happened in a chain. The solution may use a property such as sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into SA process, at launching call, check if the property set, if set, do not fork. When SA process died, it will generate core file first, note the target process still waiting for its exit, so when target exit, the core file (if both use default core as name) will be override by target. The SA process will only leave a hs_err_pid*.log file. (? read such property in handler is possible?)
>>>>
>>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>> The jars includes *app.jar and *boot.jar, the later usually can be ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent. The app.jar will contain all classes by customer, so we can do whatever we can to the jar.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>> On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
>>>>> Hi Yumin,
>>>>>
>>>>> The idea is to do as little as possible in the VM error handler, since we've crashed for some reason we don't know what state the process is in and we have to be extremely careful in when we're gathering the information. This seems like a step that is risky for all of the reasons David mentioned below.
>>>>>
>>>>> It's also information that can easily be extracted post-mortem from the core/mdmp using the method you described for OSX, so gathering this at the time of a crash seems like an unnecessary risk.
>>>>>
>>>>> Thanks,
>>>>> Christian
>>>>>
>>>>> -----Original Message-----
>>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
>>>>> Sent: Monday, August 12, 2013 1:56 AM
>>>>> To: Yumin Qi
>>>>> Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
>>>>> Subject: Re: RFR: 8020962: dump loaded java classes when vm crash
>>>>>
>>>>> Hi Yumin,
>>>>>
>>>>> Note that the SA is only present in a full JDK, not a JRE (full or compact profile).
>>>>>
>>>>> I have quite a few concerns with this:
>>>>>
>>>>> We already do a lot of things that are not valid to be done from a signal handling context but this really takes that to an extreme. Doing fork-exec from a signal handler seems like a recipe for disaster (Note the existing onError facility is typically used for synchronous failures.)
>>>>>
>>>>> The idea of launching a second VM to try and query a VM that has crashed also seems somewhat problematic:
>>>>> - What mechanism will the SA try to use to query the VM?
>>>>> - What if the state of the crashed VM stops the SA from being able to attach properly (ie both processes hang)?
>>>>> - What if it the SA also crashes, will it launch a third VM then a fourth etc?
>>>>>
>>>>> Also what is the nature of this dump? How big is it? Where will it go?
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 12/08/2013 9:36 AM, Yumin Qi wrote:
>>>>>> Hi, all
>>>>>>
>>>>>>     I would like to have your review for
>>>>>>
>>>>>> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>>>>>>
>>>>>> Description: When JVM crashed, we also want to check the application
>>>>>> class files especially we got core file from customers.  The aftermath
>>>>>> analysis will benefit from all loaded java classes available. In this
>>>>>> change, spawn another process running SA to do the job when JVM
>>>>>> crashes, this way also avoid further messing up with the error report
>>>>>> which already in signal handler.
>>>>>>
>>>>>> Note: The test has done with following two bugs worked around:
>>>>>>     8022655: ClassDump ignored jarStream setting (This will be fixed
>>>>>> and integrated by Kevin Walls soon)
>>>>>>     8011888: sa.js: TypeError: [object JSAdapter] has no such function
>>>>>> "__has__" (Not know when it will be integrated)
>>>>>>     That is, without those two fixed, the jars of loaded classes will
>>>>>> not be successfully dumped.
>>>>>>     Also, on MacOS it requires security access permission to attach to
>>>>>> another process, so omit doing so. To get loaded jar file s, with core
>>>>>> file available (on all platforms), one can (only after this
>>>>>> change) do
>>>>>>
>>>>>>     $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar
>>>>>> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Yumin


From tim.bell at oracle.com  Tue Aug 13 12:49:51 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 13 Aug 2013 12:49:51 -0700
Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang
	compiler"
In-Reply-To: <51F0AD1D.1080907@oracle.com>
References: <51EF006D.3060805@oracle.com> <51EFBDC9.4070200@oracle.com>
	<51EFC56C.6040304@oracle.com>
	<C7658F2A-6D5F-4567-BDA2-99F763B63999@oracle.com>
	<51F059A3.3080403@oracle.com> <51F0AD1D.1080907@oracle.com>
Message-ID: <520A8DDF.9020206@oracle.com>

On 07/24/13 09:44 PM, David Holmes wrote:
> On 25/07/2013 8:48 AM, Tim Bell wrote:
>> Christian:
>>
>>> That's not true.  I've added Mac OS X support with the same change.
>>
>> For building hotspot only, perhaps.  I want to build the entire product,
>> start to finish, using clang.
>>
>> That's why I needed to touch these files:
>>
>> common/autoconf/hotspot-spec.gmk.in
>> common/autoconf/toolchain.m4
>> make/jprt.properties
>
> Yes but that doesn't explain the change now needed to os_bsd.cpp in 
> hotspot.

I take it back.  After syncing up with jdk8/master, the change to 
os_bsd.cpp is not required, so I removed that.  I believe the MAX_PATH 
issues were resolved in an earlier fix.

New webrev (hotspot only):

    http://cr.openjdk.java.net/~tbell/8019470/hotspot.01/

The change in make/bsd/makefiles/gcc.make is required to link the adlc 
tool which is used early in the hotspot build.

Full webrev (OpenJDK):

http://cr.openjdk.java.net/~tbell/8019470/webrev.01/


Thanks in advance - we would like to get these changes checked in this week.

Tim


> David
> -----
>
>>
>> Tim
>>
>>
>> On 07/24/13 02:59 PM, Christian Thalinger wrote:
>>> On Jul 24, 2013, at 5:15 AM, Tim Bell <tim.bell at oracle.com> wrote:
>>>
>>>> On 07/24/13 04:43 AM, David Holmes wrote:
>>>>> Hi Tim,
>>>>>
>>>>> On 24/07/2013 8:15 AM, Tim Bell wrote:
>>>>>> Hello everyone-
>>>>>>
>>>>>> This is a small set of changes to switch from gcc to clang when
>>>>>> building
>>>>> So we already added support for clang as the compiler for hotspot -
>>>>> is this just extending things to allow configure to select clang?
>>>> The earlier clang/hotspot activity was centered around Linux 
>>>> x86/x86_64.
>>> That's not true.  I've added Mac OS X support with the same change.
>>>
>>> -- Chris
>>>
>>>>>> on MacOS, and also enable building on MacOS 8.x
>>>>> Have we already updated all the JPRT queues to have 10.8 macs versus
>>>>> 10.7 ones?
>>>> Yes, all the queues have 10.8 Macs, which have been test-only up
>>>> until now.
>>>>
>>>>>> Here is the bug report:
>>>>>>
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019470
>>>>>>
>>>>>> Here are the webrevs:
>>>>>>
>>>>>> Hotspot only:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/
>>>>> src/os/bsd/vm/os_bsd.cpp
>>>>>
>>>>> Again I'm confused. We already allowed building via clang so why
>>>>> wasn't this change needed before?
>>>> This file is not used when building on Linux.
>>>>
>>>> Tim
>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> All of the changes:
>>>>>>
>>>>>>    http://cr.openjdk.java.net/~tbell/8019470/webrev.00/
>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Tim
>>>>>>
>>


From tim.bell at oracle.com  Tue Aug 13 15:00:50 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 13 Aug 2013 15:00:50 -0700
Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang
	compiler"
In-Reply-To: <520A8DDF.9020206@oracle.com>
References: <51EF006D.3060805@oracle.com> <51EFBDC9.4070200@oracle.com>
	<51EFC56C.6040304@oracle.com>
	<C7658F2A-6D5F-4567-BDA2-99F763B63999@oracle.com>
	<51F059A3.3080403@oracle.com> <51F0AD1D.1080907@oracle.com>
	<520A8DDF.9020206@oracle.com>
Message-ID: <520AAC92.7090405@oracle.com>

I wrote:

> Thanks in advance - we would like to get these changes checked in this 
> week. 

Let me clarify this a bit - there are some bugs open against the 
MacOS/clang hotspot build that need to be resolved before considering a 
change-over to clang:

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

I would like to get the hotspot side of these changes checked in as soon 
as possible (need a sponsor for this...):

   http://cr.openjdk.java.net/~tbell/8019470/hotspot.01/

This change will do nothing unless USE_CLANG is defined to true. I'd 
like to get the hotspot side ready early so it has time to meet up with 
the next JDK8 promotion.

Thanks-

Tim

On 08/13/13 12:49 PM, Tim Bell wrote:
> On 07/24/13 09:44 PM, David Holmes wrote:
>> On 25/07/2013 8:48 AM, Tim Bell wrote:
>>> Christian:
>>>
>>>> That's not true.  I've added Mac OS X support with the same change.
>>>
>>> For building hotspot only, perhaps.  I want to build the entire 
>>> product,
>>> start to finish, using clang.
>>>
>>> That's why I needed to touch these files:
>>>
>>> common/autoconf/hotspot-spec.gmk.in
>>> common/autoconf/toolchain.m4
>>> make/jprt.properties
>>
>> Yes but that doesn't explain the change now needed to os_bsd.cpp in 
>> hotspot.
>
> I take it back.  After syncing up with jdk8/master, the change to 
> os_bsd.cpp is not required, so I removed that.  I believe the MAX_PATH 
> issues were resolved in an earlier fix.
>
> New webrev (hotspot only):
>
>    http://cr.openjdk.java.net/~tbell/8019470/hotspot.01/
>
> The change in make/bsd/makefiles/gcc.make is required to link the adlc 
> tool which is used early in the hotspot build.
>
> Full webrev (OpenJDK):
>
> http://cr.openjdk.java.net/~tbell/8019470/webrev.01/
>
>
> Thanks in advance - we would like to get these changes checked in this 
> week.
>
> Tim
>
>
>> David
>> -----
>>
>>>
>>> Tim
>>>
>>>
>>> On 07/24/13 02:59 PM, Christian Thalinger wrote:
>>>> On Jul 24, 2013, at 5:15 AM, Tim Bell <tim.bell at oracle.com> wrote:
>>>>
>>>>> On 07/24/13 04:43 AM, David Holmes wrote:
>>>>>> Hi Tim,
>>>>>>
>>>>>> On 24/07/2013 8:15 AM, Tim Bell wrote:
>>>>>>> Hello everyone-
>>>>>>>
>>>>>>> This is a small set of changes to switch from gcc to clang when
>>>>>>> building
>>>>>> So we already added support for clang as the compiler for hotspot -
>>>>>> is this just extending things to allow configure to select clang?
>>>>> The earlier clang/hotspot activity was centered around Linux 
>>>>> x86/x86_64.
>>>> That's not true.  I've added Mac OS X support with the same change.
>>>>
>>>> -- Chris
>>>>
>>>>>>> on MacOS, and also enable building on MacOS 8.x
>>>>>> Have we already updated all the JPRT queues to have 10.8 macs versus
>>>>>> 10.7 ones?
>>>>> Yes, all the queues have 10.8 Macs, which have been test-only up
>>>>> until now.
>>>>>
>>>>>>> Here is the bug report:
>>>>>>>
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019470
>>>>>>>
>>>>>>> Here are the webrevs:
>>>>>>>
>>>>>>> Hotspot only:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/
>>>>>> src/os/bsd/vm/os_bsd.cpp
>>>>>>
>>>>>> Again I'm confused. We already allowed building via clang so why
>>>>>> wasn't this change needed before?
>>>>> This file is not used when building on Linux.
>>>>>
>>>>> Tim
>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> All of the changes:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~tbell/8019470/webrev.00/
>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>
>


From ron.durbin at oracle.com  Tue Aug 13 16:42:07 2013
From: ron.durbin at oracle.com (Ron Durbin)
Date: Tue, 13 Aug 2013 16:42:07 -0700 (PDT)
Subject: JDK-8005073 open code review, (round 0)
Message-ID: <095a82a5-052e-447a-96b5-86e146566366@default>

JDK-8005073 [TESTBUG] remove crufty '_g' support from HS tests

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

Summary:

Remove all support and references to '_g' from all open test files.

OpenJDK URL:  http://cr.openjdk.java.net/~rdurbin/8005073_open_webrev/

Testing so far has included:

JPRT all platforms


From daniel.daugherty at oracle.com  Tue Aug 13 18:31:52 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 13 Aug 2013 19:31:52 -0600
Subject: JDK-8005073 open code review, (round 0)
In-Reply-To: <095a82a5-052e-447a-96b5-86e146566366@default>
References: <095a82a5-052e-447a-96b5-86e146566366@default>
Message-ID: <520ADE08.9010600@oracle.com>

On 8/13/13 5:42 PM, Ron Durbin wrote:
> JDK-8005073 [TESTBUG] remove crufty '_g' support from HS tests
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005073
>
> Summary:
>
> Remove all support and references to '_g' from all open test files.
>
> OpenJDK URL:  http://cr.openjdk.java.net/~rdurbin/8005073_open_webrev/
>
> Testing so far has included:
>
> JPRT all platforms
>

test/Makefile
     No comments.

Thumbs up.

Dan


From christian.thalinger at oracle.com  Tue Aug 13 21:18:34 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 13 Aug 2013 21:18:34 -0700
Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang
	compiler"
In-Reply-To: <520AAC92.7090405@oracle.com>
References: <51EF006D.3060805@oracle.com> <51EFBDC9.4070200@oracle.com>
	<51EFC56C.6040304@oracle.com>
	<C7658F2A-6D5F-4567-BDA2-99F763B63999@oracle.com>
	<51F059A3.3080403@oracle.com> <51F0AD1D.1080907@oracle.com>
	<520A8DDF.9020206@oracle.com> <520AAC92.7090405@oracle.com>
Message-ID: <F815A9F0-DB5C-4C06-8941-0D26B338DACB@oracle.com>


On Aug 13, 2013, at 3:00 PM, Tim Bell <tim.bell at oracle.com> wrote:

> I wrote:
> 
>> Thanks in advance - we would like to get these changes checked in this week. 
> 
> Let me clarify this a bit - there are some bugs open against the MacOS/clang hotspot build that need to be resolved before considering a change-over to clang:
> 
> http://bugs.sun.com/view_bug.do?bug_id=8021954
> http://bugs.sun.com/view_bug.do?bug_id=8022140
> 
> I would like to get the hotspot side of these changes checked in as soon as possible (need a sponsor for this...):
> 
>  http://cr.openjdk.java.net/~tbell/8019470/hotspot.01/

This looks good although I don't know why this is needed.  I build HotSpot with clang daily and I never had a problem.

-- Chris

> 
> This change will do nothing unless USE_CLANG is defined to true. I'd like to get the hotspot side ready early so it has time to meet up with the next JDK8 promotion.
> 
> Thanks-
> 
> Tim
> 
> On 08/13/13 12:49 PM, Tim Bell wrote:
>> On 07/24/13 09:44 PM, David Holmes wrote:
>>> On 25/07/2013 8:48 AM, Tim Bell wrote:
>>>> Christian:
>>>> 
>>>>> That's not true.  I've added Mac OS X support with the same change.
>>>> 
>>>> For building hotspot only, perhaps.  I want to build the entire product,
>>>> start to finish, using clang.
>>>> 
>>>> That's why I needed to touch these files:
>>>> 
>>>> common/autoconf/hotspot-spec.gmk.in
>>>> common/autoconf/toolchain.m4
>>>> make/jprt.properties
>>> 
>>> Yes but that doesn't explain the change now needed to os_bsd.cpp in hotspot.
>> 
>> I take it back.  After syncing up with jdk8/master, the change to os_bsd.cpp is not required, so I removed that.  I believe the MAX_PATH issues were resolved in an earlier fix.
>> 
>> New webrev (hotspot only):
>> 
>>   http://cr.openjdk.java.net/~tbell/8019470/hotspot.01/
>> 
>> The change in make/bsd/makefiles/gcc.make is required to link the adlc tool which is used early in the hotspot build.
>> 
>> Full webrev (OpenJDK):
>> 
>> http://cr.openjdk.java.net/~tbell/8019470/webrev.01/
>> 
>> 
>> Thanks in advance - we would like to get these changes checked in this week.
>> 
>> Tim
>> 
>> 
>>> David
>>> -----
>>> 
>>>> 
>>>> Tim
>>>> 
>>>> 
>>>> On 07/24/13 02:59 PM, Christian Thalinger wrote:
>>>>> On Jul 24, 2013, at 5:15 AM, Tim Bell <tim.bell at oracle.com> wrote:
>>>>> 
>>>>>> On 07/24/13 04:43 AM, David Holmes wrote:
>>>>>>> Hi Tim,
>>>>>>> 
>>>>>>> On 24/07/2013 8:15 AM, Tim Bell wrote:
>>>>>>>> Hello everyone-
>>>>>>>> 
>>>>>>>> This is a small set of changes to switch from gcc to clang when
>>>>>>>> building
>>>>>>> So we already added support for clang as the compiler for hotspot -
>>>>>>> is this just extending things to allow configure to select clang?
>>>>>> The earlier clang/hotspot activity was centered around Linux x86/x86_64.
>>>>> That's not true.  I've added Mac OS X support with the same change.
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>>>>> on MacOS, and also enable building on MacOS 8.x
>>>>>>> Have we already updated all the JPRT queues to have 10.8 macs versus
>>>>>>> 10.7 ones?
>>>>>> Yes, all the queues have 10.8 Macs, which have been test-only up
>>>>>> until now.
>>>>>> 
>>>>>>>> Here is the bug report:
>>>>>>>> 
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019470
>>>>>>>> 
>>>>>>>> Here are the webrevs:
>>>>>>>> 
>>>>>>>> Hotspot only:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/
>>>>>>> src/os/bsd/vm/os_bsd.cpp
>>>>>>> 
>>>>>>> Again I'm confused. We already allowed building via clang so why
>>>>>>> wasn't this change needed before?
>>>>>> This file is not used when building on Linux.
>>>>>> 
>>>>>> Tim
>>>>>> 
>>>>>>> Thanks,
>>>>>>> David
>>>>>>> 
>>>>>>>> All of the changes:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~tbell/8019470/webrev.00/
>>>>>>> 
>>>>>>>> Thanks in advance.
>>>>>>>> 
>>>>>>>> Tim
>>>>>>>> 
>>>> 
>> 
> 


From mikael.gerdin at oracle.com  Wed Aug 14 01:39:04 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 14 Aug 2013 10:39:04 +0200
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
Message-ID: <520B4228.7000307@oracle.com>

Harold,

On 2013-08-09 16:57, Harold Seigel wrote:
> Hi,
>
> Please review this latest version of the bug fix for 8003424:
> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/
>
>
> This new version includes the following changes:
>
> 1. macroAssembler_sparc.cpp
>
>     a. Merged two versions of reinit_heapbase() into one.
>
>     b. Improved decode_klass_not_null(src, dst) to not use G6 if shift == 0.
>
>
> 2. macroAssembler_x86.cpp
>
>     a. Merged two versions of reinit_heapbase() into one.
>
>     b. Improved encode_klass_not_null(src, dst) to not use R12.
>
>     c. Replaced leaq with addq in decode_klass_not_null(src, dst).
>
>
> 3. Improved variable names in heap.cpp.
>
>
> 4. metaspace.cpp
>
>     a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more
> understandable.
>
>     b. Moved set_narrow_klass_base_and_shift() near
> can_use_cds_with_metaspace_addr().
>
>     c. Changed unneeded conditional in initialize_class_space() into an
> assert.
>
>
> 5. arguments.cpp
>
>     a. Fixed problem with -Xshare:dump and disabled compression.
>
>     b. Moved UseCompressedKlassPointers code into new function:
> set_use_compressed_klass_ptrs().
>
>     c. Fixed bug 8005933 that turned off CDS for -server even if
> -Xshare:auto was explicitly specified.
>
>
> 6. Increased default value of ClassMetaspaceSize to 1*G in globals.hpp.
>
>
> 7. Fixed indentation issues in metaspace.cpp and other modules.

The VM changes look good to me.

I have a question about the test CDSCompressedKPtrs.java

What RuntimeException do you expect and why is it ok that we can't use 
the shared archive if you get such an exception?

I think at least a comment about why the test is supposed to pass even 
if we can't use the shared archive.

/Mikael

>
>
> Thanks, Harold
>
> ----- Original Message -----
> From: harold.seigel at oracle.com
> To: coleen.phillimore at oracle.com
> Cc: hotspot-runtime-dev at openjdk.java.net
> Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern
> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
> CompressedOops
>
> The purpose of this assert is to verify that the two methods in the 'if'
> clause closed the map file and disabled UseSharedSpaces if they detected
> a problem when trying to use CDS.
>
>        if (mapinfo->initialize() &&
> MetaspaceShared::map_shared_spaces(mapinfo)) {
>          FileMapInfo::set_current_info(mapinfo);
>        } else {
>          assert(!mapinfo->is_open() && !UseSharedSpaces,
>                 "archive file not closed or shared spaces not disabled.");
>        }
>
> ----- Original Message -----
> From: harold.seigel at oracle.com
> To: coleen.phillimore at oracle.com
> Cc: hotspot-runtime-dev at openjdk.java.net
> Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
> CompressedOops
>
> This is a bug that Stefan Karlsson also discovered.  To fix it, I've
> changed the code to this:
>
>    if (DumpSharedSpaces) {
>      if (RequireSharedSpaces) {
>        warning("cannot dump shared archive while using shared archive");
>      }
>      UseSharedSpaces = false;
> #ifdef _LP64
>      if (!UseCompressedOops || !UseCompressedKlassPointers) {
>        vm_exit_during_initialization(
>          "Cannot dump shared archive when UseCompressedOops or
> UseCompressedKlassPointers is off.", NULL);
>      }
>
> Harold
>
>
> ----- Original Message -----
> From: coleen.phillimore at oracle.com
> To: hotspot-runtime-dev at openjdk.java.net
> Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
> CompressedOops
>
>
> Yes, there should be a check for that too.  Now I'll really let Harold
> answer.
>
> Thanks,
> Coleen
>
> On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
>  > Coleen, Harold
>  >
>  > > The InstanceKlass has offsets to fields in the instance, and they
>  > depend
>  > > on both compressed oops and compressed klass pointers.   So both
>  > have to
>  > > be on for the offsets to be valid.
>  >
>  > So there is dependency on UseCompressedOops and
>  > UseCompressedKlassPointers flags during dump.
>  >
>  > Then why the check is done only for UseSharedSpaces and not for
>  > DumpSharedSpaces?:
>  >
>  >     if (DumpSharedSpaces) {
>  >       if (RequireSharedSpaces) {
>  >         warning("cannot dump shared archive while using shared archive");
>  >       }
>  >       UseSharedSpaces = false;
>  > + #ifdef _LP64
>  > +   } else {
>  > +     // UseCompressedOops and UseCompressedKlassPointers must be on
>  > for UseSharedSpaces.
>  > +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>  > +       no_shared_spaces();
>  > +     }
>  > + #endif
>  >     }
>  >
>  > Thanks,
>  > Vladimir
>  >
>  > On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>  >>
>  >> Hi Vladimir,
>  >>
>  >> I have a couple of answers and I'll let Harold answer the rest.
>  >>
>  >> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>  >>> On 8/7/13 8:34 AM, harold seigel wrote:
>  >>>> Hi Vladimir,
>  >>>>
>  >>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>  >>>>> Harold,
>  >>>>>
>  >>>>> Note, on SPARC set() could generate up to 8 instructions to load
>  >>>>> 64-bit constant into register. So I am not sure that it will be
>  >>>>> faster
>  >>>>> than load.
>  >>>> We thought it would be faster because it doesn't need to load anything
>  >>>> from memory.
>  >>>
>  >>> For good value (0x800000000) it should use only 2-3 instructions.
>  >>> I think you can keep using set().
>  >>>
>  >>>>>
>  >>>>> I can't find where in CDS you store information about compressed
>  >>>>> klass
>  >>>>> pointers and compressed oops parameters which were used during dump?
>  >>>>> How you verify that correct parameters/flags are ussed when such CDS
>  >>>>> is used later?
>  >>>> No compressed klass pointers nor compressed oops get written to the
>  >>>> archive.  So, the compressed klass pointers and compressed oops
>  >>>> parameters do not need to be recorded in the archive.
>  >>>
>  >>> So you are saying that all klass pointers (references to klasses) in
>  >>> metadata structures in metaspace are full.
>  >>
>  >> Yes, they are.  (methodOops weren't in the InstanceKlass::_methods array
>  >> with Permgen but they are uncompressed now).
>  >>
>  >>> And klass pointers are only compressed in java object headers (which
>  >>> are not part of CDS). Right?
>  >>
>  >> The InstanceKlass has offsets to fields in the instance, and they depend
>  >> on both compressed oops and compressed klass pointers.   So both have to
>  >> be on for the offsets to be valid.
>  >>
>  >> But the base and compressed values are not stored anywhere in the CDS
>  >> archive.
>  >>
>  >>> And you don't care about UseCompressedOops and
>  >>> UseCompressedKlassPointers flags settings when you dump it into
>  >>> archive. The only limit is:
>  >>>
>  >>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - cds_total
>  >>>
>  >>> Then I don't understand why you can't use/load CDS archive when coop
>  >>> or compklass are off:
>  >>>
>  >>> > If coop is turned off then CDS cannot be used.  CDS will only be
>  >>> > supported if both UseCompressedOops and UseCompressedKlassPointers
>  >>> are
>  >>> > TRUE.
>  >>>
>  >>> Also based on code in arguments.cpp it is allowed to specify
>  >>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on command line:
>  >>>
>  >>> 1466     // Turn on UseCompressedKlassPointers too
>  >>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>  >>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>  >>> 1469     }
>  >>>
>  >>> Did you tested such combination?
>  >>
>  >> I should let Harold answer this but I believe this is what his test
>  >> does.  For CDS on 64 bit, both must be on.   We didn't want to create 4
>  >> different archives.   And it wouldn't make too much sense since CDS for
>  >> 64 bit is a footprint savings so why would you use it without
>  >> compressing oops and class pointers?  It's not a startup savings on
>  >> server because we turn off interpreter bytecode quickening.
>  >>
>  >> Coleen
>  >>
>  >>>
>  >>>>>
>  >>>>> set_narrow_klass_base_and_shift() and
>  >>>>> can_use_cds_with_metaspace_addr() have the same code for
>  >>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>  >>>>> can_use_cds_with_metaspace_addr() from
>  >>>>> set_narrow_klass_base_and_shift() ?
>  >>>> I could add new inlined methods that determine the higher_address and
>  >>>> lower_base when UseSharedSpaces is true and have them called from
>  >>>> set_narrow_klass_base_and_shift() and
>  >>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>  >>>
>  >>> I tried several approaches but your implementation is more clean. So I
>  >>> agree to keep what you have now.
>  >>>
>  >>>
>  >>> Also I found strange assert which should always fail (old code in
>  >>> global_initialize() in metaspace.cpp):
>  >>>
>  >>> 2959     if (UseSharedSpaces) {
>  >>> ...
>  >>> 2969       } else {
>  >>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>  >>> 2971                "archive file not closed or shared spaces not
>  >>> disabled.");
>  >>>
>  >>> Thanks,
>  >>> Vladimir
>  >>>
>  >>>>>
>  >>>>> I see that you unconditionally set comp klass ptr base and shift for
>  >>>>> DumpSharedSpaces. Should you do the check similar to
>  >>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>  >>>>> don't even check UseCompressedKlassPointers.
>  >>>> I don't think the checks are needed because the information written to
>  >>>> the archive is not affected by the size of the class metaspace.
>  >>>>
>  >>>> Also, I recently added code to arguments.cpp that will generate an
>  >>>> error
>  >>>> if UseCompressedOops or UseCompressedKlassPointers is turned off and
>  >>>> DumpSharedSpaces is on.
>  >>>>>
>  >>>>> Why you have next limitation? What if coop can't be used because of
>  >>>>> big heap?:
>  >>>>>
>  >>>>> +     // UseCompressedOops and UseCompressedKlassPointers must be on
>  >>>>> for UseSharedSpaces.
>  >>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>  >>>>> +       no_shared_spaces();
>  >>>> If coop is turned off then CDS cannot be used.  CDS will only be
>  >>>> supported if both UseCompressedOops and UseCompressedKlassPointers are
>  >>>> TRUE.
>  >>>>>
>  >>>>> Could you move UseCompressedKlassPointers code in arguments.cpp into
>  >>>>> separate method similar to set_use_compressed_oops()?
>  >>>> Done.
>  >>>>>
>  >>>>> About new tests.
>  >>>>> The first test in CDSCompressedKPtrsError misses
>  >>>>> -XX:+UseCompressedOops flag.
>  >>>> Fixed.
>  >>>>>
>  >>>>> Could you also test cross flags combinations?:
>  >>>>>
>  >>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>  >>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>  >>>> Done.
>  >>>>>
>  >>>>> It would be nice to have test to check ClassMetaspaceSize value
>  >>>>> range.
>  >>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither maxint
>  >>>>> or maxuint.
>  >>>> A member of our runtime SQE group is writing additional tests. I'll
>  >>>> ask
>  >>>> him to write a ClassMetaspaceSize range test.
>  >>>>
>  >>>> We chose 3Gb because we thought it was a sufficiently large size.
>  >>>>>
>  >>>>>
>  >>>>> About code style, indention. We align next line to corresponding part
>  >>>>> of previous line if we need to split a line. And sometimes it is
>  >>>>> better to keep one long line. I understand some of them were before
>  >>>>> your changes but, please, clean up at lest ones you touched.
>  >>>> Done.
>  >>>>>
>  >>>>> Cases in metaspace.cpp:
>  >>>>>
>  >>>>> 2263   assert(raw_word_size >= min_size,
>  >>>>> 2264     err_msg("Should not deallocate dark matter " SIZE_FORMAT "<"
>  >>>>> SIZE_FORMAT, word_size, min_size));
>  >>>>>
>  >>>>>
>  >>>>> 2485   if (Metaspace::using_class_space() &&
>  >>>>> 2486     (Metaspace::class_space_list() != NULL)) {
>  >>>>>
>  >>>>>
>  >>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>  >>>>> 2575                       (Metaspace::using_class_space() ?
>  >>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>  >>>>> 2577 Metaspace::space_list()->virtual_space_total();
>  >>>>>
>  >>>>>
>  >>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>  >>>>> SIZE_FORMAT ", "
>  >>>>> 2695                            SIZE_FORMAT " small(s) " SIZE_FORMAT
>  >>>>> ", "
>  >>>>> 2696                            SIZE_FORMAT " medium(s) " SIZE_FORMAT
>  >>>>> ", "
>  >>>>> 2697                            "large count " SIZE_FORMAT,
>  >>>>> 2698              cls_specialized_count, cls_specialized_waste,
>  >>>>> 2699              cls_small_count, cls_small_waste,
>  >>>>> 2700              cls_medium_count, cls_medium_waste,
>  >>>>> cls_humongous_count);
>  >>>>>
>  >>>>>
>  >>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G >
>  >>>>> addr) &&
>  >>>>> 2873         can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>  >>>>>
>  >>>>>
>  >>>>> 2889         vm_exit_during_initialization(err_msg(
>  >>>>> 2890           "Could not allocate metaspace: %d bytes",
>  >>>>> 2891           class_metaspace_size()));
>  >>>>>
>  >>>>>
>  >>>>> 3107     return using_class_space() ?
>  >>>>> 3108       class_vsm()->sum_used_in_chunks_in_use() : 0;
>  >>>>>
>  >>>>>
>  >>>>> 3157     if (is_class && using_class_space()) {
>  >>>>> 3158        class_vsm()->deallocate(ptr, word_size);
>  >>>>>
>  >>>>>
>  >>>>> 3305   return space_list()->contains(ptr) ||
>  >>>>> 3306     (using_class_space() && class_space_list()->contains(ptr));
>  >>>>>
>  >>>>> metaspace.hpp:
>  >>>>>
>  >>>>>  270     return _allocated_capacity_words[Metaspace::NonClassType] +
>  >>>>>  271       (Metaspace::using_class_space() ?
>  >>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>  >>>>>
>  >>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>  >>>>>  286       (Metaspace::using_class_space() ?
>  >>>>>  287         _allocated_used_words[Metaspace::ClassType] : 0);
>  >>>>>
>  >>>>> universe.cpp:
>  >>>>>
>  >>>>>  849   assert((intptr_t)Universe::narrow_oop_base() <=
>  >>>>> (intptr_t)(Universe::heap()->base() -
>  >>>>>  850     os::vm_page_size()) ||
>  >>>>>  851            Universe::narrow_oop_base() == NULL, "invalid
>  >>>>> value");
>  >>>>>
>  >>>>>
>  >>>>> Thanks,
>  >>>>> Vladimir
>  >>>>>
>  >>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>  >>>>>> Hi,
>  >>>>>>
>  >>>>>> Please review this updated webrev for bug 8003424:
>  >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>  >>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>  >>>>>>
>  >>>>>> The updated webrev has a lot of changes from the previous webrev,
>  >>>>>> including the following:
>  >>>>>>
>  >>>>>>     1. Class metaspace information is now output when
>  >>>>>>     -XX:+PrintCompressedOopsMode is specified.
>  >>>>>>
>  >>>>>>     2. decode_klass_not_null(Register dst, Register src) no longer
>  >>>>>>     clobbers R12.
>  >>>>>>
>  >>>>>>     3. Method using_class_vsm() was renamed to using_class_space().
>  >>>>>>
>  >>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>  >>>>>> appropriate.
>  >>>>>>
>  >>>>>>     5. The Metaspace:: qualifier was removed, where it was
>  >>>>>> unnecessary.
>  >>>>>>
>  >>>>>>     6. Metaspace::initialize_class_space() was made private.
>  >>>>>>
>  >>>>>>     7. Method max_heap_for_compressed_oops(), in arguments.cpp, was
>  >>>>>> updated.
>  >>>>>>
>  >>>>>> Performance tests were run by Jenny using specjvm2008, specjbb2005,
>  >>>>>> and
>  >>>>>> specjbb2013.  The results showed no significant performance
>  >>>>>> difference
>  >>>>>> in terms of scores and gc behavior.
>  >>>>>>
>  >>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>  >>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>  >>>>>>
>  >>>>>> Please let me know what additional tests should be run.
>  >>>>>>
>  >>>>>> Thanks!
>  >>>>>> Harold
>  >>>>>>
>  >>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>  >>>>>>> Hi Harold,
>  >>>>>>>
>  >>>>>>> > Usually the narrow_klass_base will be 32G and the
>  >>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which
>  >>>>>>> means
>  >>>>>>> that
>  >>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>  >>>>>>> unless
>  >>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does that
>  >>>>>>> make
>  >>>>>>> sense?
>  >>>>>>>
>  >>>>>>> My bad, I miscalculated. But we have "perfect value" 0x800000000
>  >>>>>>> and I
>  >>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>  >>>>>>> (assuming or
>  >>>>>>> with check that class metaspace size < 32Gb).
>  >>>>>>>
>  >>>>>>> > Is there one prefix byte per instruction, or just for certain
>  >>>>>>> instructions?
>  >>>>>>>
>  >>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>  >>>>>>> prefix is
>  >>>>>>> necessary only if an instruction references one of the extended
>  >>>>>>> registers or uses a 64-bit operand."
>  >>>>>>>
>  >>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 and
>  >>>>>>> =32
>  >>>>>>> and big java heap. Recently we got several bugs which indicated
>  >>>>>>> that
>  >>>>>>> we did not separate cleanly oops and klass pointers en/decoding.
>  >>>>>>>
>  >>>>>>> Thanks,
>  >>>>>>> Vladimir
>  >>>>>>>
>  >>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>  >>>>>>>> Hi Vladimir,
>  >>>>>>>>
>  >>>>>>>> Thank you for the review!  Please see inline comments.
>  >>>>>>>>
>  >>>>>>>> Thanks, Harold
>  >>>>>>>>
>  >>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>  >>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>  >>>>>>>>>> Nice clean up, Harold
>  >>>>>>>>>>
>  >>>>>>>>>> Could you add the size of class metaspace in output with
>  >>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>  >>>>>>>>>> remember an
>  >>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>  >>>>>>>> Will be done in next webrev.
>  >>>>>>>>>>
>  >>>>>>>>>> Also it would be nice to print these info line (and compressed
>  >>>>>>>>>> oops
>  >>>>>>>>>> info
>  >>>>>>>>>> line) in hs_err files.
>  >>>>>>>> I filed an enhancement bug for this: 8021264
>  >>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>  >>>>>>>>>>
>  >>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>  >>>>>>>>>> x86_64.ad.
>  >>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use
>  >>>>>>>>>> arithmetic
>  >>>>>>>>>> instructions which modify flags: subq, addq, shrq, xorptr. Also
>  >>>>>>>>>> note
>  >>>>>>>>>> that code in .ad file does not check the encoding mode for
>  >>>>>>>>>> narrow
>  >>>>>>>>>> klass/oop so it should be conservative and assume that
>  >>>>>>>>>> arithmetic
>  >>>>>>>>>> instructions are used.
>  >>>>>>>> OK. Thanks.
>  >>>>>>>>>>
>  >>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass base below
>  >>>>>>>>>> 4Gb so
>  >>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>  >>>>>>>>>> encoding/decoding without destroying R12.
>  >>>>>>>>>
>  >>>>>>>>> Correction. You can do it only if base < 2Gb max positive int
>  >>>>>>>>> (sign
>  >>>>>>>>> bit is extended so you will get wrong result with address > 2gb).
>  >>>>>>>> But the base will normally be 32Gb.  So this case won't happen
>  >>>>>>>> very
>  >>>>>>>> often.
>  >>>>>>>>>
>  >>>>>>>>> You definitely should not use R12 in
>  >>>>>>>>> decode_klass_not_null(Register
>  >>>>>>>>> dst, Register src) method where you have free 'dst' register.
>  >>>>>>>> Will be fixed in next webrev.
>  >>>>>>>>>
>  >>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). Actually it
>  >>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be
>  >>>>>>>>> 64Gb.
>  >>>>>>>>> The idea was to avoid using R12 by using shifted base:
>  >>>>>>>>>
>  >>>>>>>>> decode:
>  >>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>  >>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>  >>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>  >>>>>>>>>   }
>  >>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>  >>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>  >>>>>>>>> }
>  >>>>>>>>>
>  >>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>  >>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <=
>  >>>>>>>>> maxint
>  >>>>>>>>> (max positive int).
>  >>>>>>>> Usually the narrow_klass_base will be 32G and the
>  >>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which means
>  >>>>>>>> that
>  >>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need R12,
>  >>>>>>>> unless
>  >>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that
>  >>>>>>>> make
>  >>>>>>>> sense?
>  >>>>>>>>>
>  >>>>>>>>> And you have general memory reservation problem. At least on
>  >>>>>>>>> Solaris,
>  >>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
>  >>>>>>>>> between
>  >>>>>>>>> different requested memory regions. That is why in jdk7 we first
>  >>>>>>>>> reserve one huge space and then cut it on java heap, perm gen and
>  >>>>>>>>> protection page below heap to catch implicit NULL exceptions with
>  >>>>>>>>> compressed oops.
>  >>>>>>>>>
>  >>>>>>>>> So, please, verify that you are getting 'cds_address + cds_total'
>  >>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>  >>>>>>>>> compressed
>  >>>>>>>>> oops and with Xmx20Gb.
>  >>>>>>>> I verifed that we get either cds_address+cds_total as the
>  >>>>>>>> address, or
>  >>>>>>>> CompressedKlassPointersBase as the address without CDS on Linux,
>  >>>>>>>> Windows
>  >>>>>>>> 7, Mac OS, and Solaris 5.11.  This is true with default heap
>  >>>>>>>> sizes and
>  >>>>>>>> -Xmx32G.
>  >>>>>>>>
>  >>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or the
>  >>>>>>>> desired
>  >>>>>>>> CDS address for class metaspace regardless of heap size.
>  >>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>  >>>>>>>>>> unfortunately we
>  >>>>>>>>>> can't do other way. I assume you use max size because
>  >>>>>>>>>> depending on
>  >>>>>>>>>> registers used in instructions you will or will not get prefix
>  >>>>>>>>>> byte
>  >>>>>>>>>> (r8-r15).
>  >>>>>>>> Is there one prefix byte per instruction, or just for certain
>  >>>>>>>> instructions?
>  >>>>>>>>>>
>  >>>>>>>>>> I will look on changes in more details may be late.
>  >>>>>>>>>
>  >>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use
>  >>>>>>>>> abbreviations
>  >>>>>>>>> which are not obvious.
>  >>>>>>>> I changed using_class_vsm() to using_class_space().
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>> Thanks,
>  >>>>>>>>>> Vladimir
>  >>>>>>>>>>
>  >>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>  >>>>>>>>>>> Hi,
>  >>>>>>>>>>>
>  >>>>>>>>>>> Please review this fix for bug 8003424.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003424/
>  >>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>  >>>>>>>>>>> Open bug links at:
>  >>>>>>>>>>>
>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>  >>>>>>>>>>>
>  >>>>>>>>>>> JBS Bug links at
>  >>>>>>>>>>>
>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>> This fix provides support for using compressed klass pointers
>  >>>>>>>>>>> with
>  >>>>>>>>>>> CDS.
>  >>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>  >>>>>>>>>>> platforms
>  >>>>>>>>>>> when
>  >>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of allocating the
>  >>>>>>>>>>> class
>  >>>>>>>>>>> metaspace as part of the Java Heap allocation and locating
>  >>>>>>>>>>> it at
>  >>>>>>>>>>> the
>  >>>>>>>>>>> base of that allocation, the metaspace will now be allocated
>  >>>>>>>>>>> separately,
>  >>>>>>>>>>> above the Java heap.  This will enable future expansion of the
>  >>>>>>>>>>> metaspace
>  >>>>>>>>>>> because it won't be backed up against the Java heap. If CDS is
>  >>>>>>>>>>> being
>  >>>>>>>>>>> used, then the CDS region will be allocated between the Java
>  >>>>>>>>>>> heap and
>  >>>>>>>>>>> the metaspace.
>  >>>>>>>>>>>
>  >>>>>>>>>>> The new class metaspace allocation code tries to allocate
>  >>>>>>>>>>> memory at
>  >>>>>>>>>>> 32G,
>  >>>>>>>>>>> or above the CDS region, if it is present. Because of this,
>  >>>>>>>>>>> encoding
>  >>>>>>>>>>> and decoding of compressed klass pointers will always
>  >>>>>>>>>>> require use
>  >>>>>>>>>>> of a
>  >>>>>>>>>>> base register.  So, encoding and decoding of compressed klass
>  >>>>>>>>>>> pointers
>  >>>>>>>>>>> will differ from compressed oops.
>  >>>>>>>>>>>
>  >>>>>>>>>>> There are no class metaspace allocation changes if
>  >>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
>  >>>>>>>>>>> 32-bit
>  >>>>>>>>>>> platform.
>  >>>>>>>>>>>
>  >>>>>>>>>>> The code changes also include some cleanup and will fix bugs
>  >>>>>>>>>>> 8016729,
>  >>>>>>>>>>> 8011610, and 8003424.
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>> Many of the modules in this webrev contain a lot of changes.
>  >>>>>>>>>>> Modules
>  >>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>  >>>>>>>>>>> changed to
>  >>>>>>>>>>> support the new encoding and decoding of compressed klass
>  >>>>>>>>>>> pointers.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Module metaspace.cpp was changed significantly to support
>  >>>>>>>>>>> the new
>  >>>>>>>>>>> allocation for metaspace and the CDS region and to determine
>  >>>>>>>>>>> compressed
>  >>>>>>>>>>> klass pointer encoding base and shifting values.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Most of the changes to module universe.cpp were to remove code
>  >>>>>>>>>>> related
>  >>>>>>>>>>> to allocating metaspace and remove code that considered
>  >>>>>>>>>>> compressed
>  >>>>>>>>>>> klass
>  >>>>>>>>>>> pointers when determining the compressed oops compression
>  >>>>>>>>>>> mechanism.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as
>  >>>>>>>>>>> part
>  >>>>>>>>>>> of a
>  >>>>>>>>>>> cleanup requested by Coleen.
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
>  >>>>>>>>>>> tests,
>  >>>>>>>>>>> JPRT,
>  >>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and
>  >>>>>>>>>>> vm.mlvm.testlist
>  >>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and
>  >>>>>>>>>>> -Xshare:off
>  >>>>>>>>>>> (with
>  >>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit
>  >>>>>>>>>>> Linux and
>  >>>>>>>>>>> 64-Bit
>  >>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. JCK tests
>  >>>>>>>>>>> were
>  >>>>>>>>>>> run on Solaris x86.
>  >>>>>>>>>>>
>  >>>>>>>>>>> The performance impact of these changes is TBD.
>  >>>>>>>>>>>
>  >>>>>>>>>>> Thanks, Harold
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>
>  >>>>>>
>  >>>>
>  >>
>

From staffan.larsen at oracle.com  Wed Aug 14 04:53:17 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 14 Aug 2013 13:53:17 +0200
Subject: JDK-8005073 open code review, (round 0)
In-Reply-To: <095a82a5-052e-447a-96b5-86e146566366@default>
References: <095a82a5-052e-447a-96b5-86e146566366@default>
Message-ID: <25198B11-0FEA-4A97-832B-ED023FF2E5D5@oracle.com>

Looks good!

/Staffan

On 14 aug 2013, at 01:42, Ron Durbin <ron.durbin at oracle.com> wrote:

> JDK-8005073 [TESTBUG] remove crufty '_g' support from HS tests
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005073
> 
> Summary:
> 
> Remove all support and references to '_g' from all open test files.
> 
> OpenJDK URL:  http://cr.openjdk.java.net/~rdurbin/8005073_open_webrev/
> 
> Testing so far has included:
> 
> JPRT all platforms
> 


From harold.seigel at oracle.com  Wed Aug 14 05:18:20 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 14 Aug 2013 08:18:20 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <520B4228.7000307@oracle.com>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
	<520B4228.7000307@oracle.com>
Message-ID: <520B758C.2080405@oracle.com>

Hi Mikael,

Thanks for the review.

In test CDSCompressedKPtrs.java, RuntimeException gets thrown by 
output.shouldContain(), if it does not find the specified text in the 
test's output.  In this test, it may not find "sharing" in the test 
output if the JVM was unable to compatibly allocate the class 
metaspace.  If the class metaspace does not get allocated near the CDS 
region then the JVM turns off CDS, disabling sharing.  Since this is a 
valid execution path, it shouldn't cause the test to fail.

I've added a comment and changed the test a bit to try and make it clearer:

       } catch (RuntimeException e) {
         // Report 'passed' if CDS was turned off because we could not 
allocate
         // the klass metaspace at an address that would work with CDS.
         output.shouldContain("Could not allocate metaspace at a 
compatible address");
         output.shouldHaveExitValue(1);
       }

Thanks, Harold

On 8/14/2013 4:39 AM, Mikael Gerdin wrote:
> Harold,
>
> On 2013-08-09 16:57, Harold Seigel wrote:
>> Hi,
>>
>> Please review this latest version of the bug fix for 8003424:
>> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/
>>
>>
>> This new version includes the following changes:
>>
>> 1. macroAssembler_sparc.cpp
>>
>>     a. Merged two versions of reinit_heapbase() into one.
>>
>>     b. Improved decode_klass_not_null(src, dst) to not use G6 if 
>> shift == 0.
>>
>>
>> 2. macroAssembler_x86.cpp
>>
>>     a. Merged two versions of reinit_heapbase() into one.
>>
>>     b. Improved encode_klass_not_null(src, dst) to not use R12.
>>
>>     c. Replaced leaq with addq in decode_klass_not_null(src, dst).
>>
>>
>> 3. Improved variable names in heap.cpp.
>>
>>
>> 4. metaspace.cpp
>>
>>     a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more
>> understandable.
>>
>>     b. Moved set_narrow_klass_base_and_shift() near
>> can_use_cds_with_metaspace_addr().
>>
>>     c. Changed unneeded conditional in initialize_class_space() into an
>> assert.
>>
>>
>> 5. arguments.cpp
>>
>>     a. Fixed problem with -Xshare:dump and disabled compression.
>>
>>     b. Moved UseCompressedKlassPointers code into new function:
>> set_use_compressed_klass_ptrs().
>>
>>     c. Fixed bug 8005933 that turned off CDS for -server even if
>> -Xshare:auto was explicitly specified.
>>
>>
>> 6. Increased default value of ClassMetaspaceSize to 1*G in globals.hpp.
>>
>>
>> 7. Fixed indentation issues in metaspace.cpp and other modules.
>
> The VM changes look good to me.
>
> I have a question about the test CDSCompressedKPtrs.java
>
> What RuntimeException do you expect and why is it ok that we can't use 
> the shared archive if you get such an exception?
>
> I think at least a comment about why the test is supposed to pass even 
> if we can't use the shared archive.
>
> /Mikael
>
>>
>>
>> Thanks, Harold
>>
>> ----- Original Message -----
>> From: harold.seigel at oracle.com
>> To: coleen.phillimore at oracle.com
>> Cc: hotspot-runtime-dev at openjdk.java.net
>> Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern
>> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
>> CompressedOops
>>
>> The purpose of this assert is to verify that the two methods in the 'if'
>> clause closed the map file and disabled UseSharedSpaces if they detected
>> a problem when trying to use CDS.
>>
>>        if (mapinfo->initialize() &&
>> MetaspaceShared::map_shared_spaces(mapinfo)) {
>>          FileMapInfo::set_current_info(mapinfo);
>>        } else {
>>          assert(!mapinfo->is_open() && !UseSharedSpaces,
>>                 "archive file not closed or shared spaces not 
>> disabled.");
>>        }
>>
>> ----- Original Message -----
>> From: harold.seigel at oracle.com
>> To: coleen.phillimore at oracle.com
>> Cc: hotspot-runtime-dev at openjdk.java.net
>> Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
>> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
>> CompressedOops
>>
>> This is a bug that Stefan Karlsson also discovered.  To fix it, I've
>> changed the code to this:
>>
>>    if (DumpSharedSpaces) {
>>      if (RequireSharedSpaces) {
>>        warning("cannot dump shared archive while using shared archive");
>>      }
>>      UseSharedSpaces = false;
>> #ifdef _LP64
>>      if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>        vm_exit_during_initialization(
>>          "Cannot dump shared archive when UseCompressedOops or
>> UseCompressedKlassPointers is off.", NULL);
>>      }
>>
>> Harold
>>
>>
>> ----- Original Message -----
>> From: coleen.phillimore at oracle.com
>> To: hotspot-runtime-dev at openjdk.java.net
>> Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
>> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
>> CompressedOops
>>
>>
>> Yes, there should be a check for that too.  Now I'll really let Harold
>> answer.
>>
>> Thanks,
>> Coleen
>>
>> On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
>>  > Coleen, Harold
>>  >
>>  > > The InstanceKlass has offsets to fields in the instance, and they
>>  > depend
>>  > > on both compressed oops and compressed klass pointers.   So both
>>  > have to
>>  > > be on for the offsets to be valid.
>>  >
>>  > So there is dependency on UseCompressedOops and
>>  > UseCompressedKlassPointers flags during dump.
>>  >
>>  > Then why the check is done only for UseSharedSpaces and not for
>>  > DumpSharedSpaces?:
>>  >
>>  >     if (DumpSharedSpaces) {
>>  >       if (RequireSharedSpaces) {
>>  >         warning("cannot dump shared archive while using shared 
>> archive");
>>  >       }
>>  >       UseSharedSpaces = false;
>>  > + #ifdef _LP64
>>  > +   } else {
>>  > +     // UseCompressedOops and UseCompressedKlassPointers must be on
>>  > for UseSharedSpaces.
>>  > +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>  > +       no_shared_spaces();
>>  > +     }
>>  > + #endif
>>  >     }
>>  >
>>  > Thanks,
>>  > Vladimir
>>  >
>>  > On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>>  >>
>>  >> Hi Vladimir,
>>  >>
>>  >> I have a couple of answers and I'll let Harold answer the rest.
>>  >>
>>  >> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>>  >>> On 8/7/13 8:34 AM, harold seigel wrote:
>>  >>>> Hi Vladimir,
>>  >>>>
>>  >>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>  >>>>> Harold,
>>  >>>>>
>>  >>>>> Note, on SPARC set() could generate up to 8 instructions to load
>>  >>>>> 64-bit constant into register. So I am not sure that it will be
>>  >>>>> faster
>>  >>>>> than load.
>>  >>>> We thought it would be faster because it doesn't need to load 
>> anything
>>  >>>> from memory.
>>  >>>
>>  >>> For good value (0x800000000) it should use only 2-3 instructions.
>>  >>> I think you can keep using set().
>>  >>>
>>  >>>>>
>>  >>>>> I can't find where in CDS you store information about compressed
>>  >>>>> klass
>>  >>>>> pointers and compressed oops parameters which were used during 
>> dump?
>>  >>>>> How you verify that correct parameters/flags are ussed when 
>> such CDS
>>  >>>>> is used later?
>>  >>>> No compressed klass pointers nor compressed oops get written to 
>> the
>>  >>>> archive.  So, the compressed klass pointers and compressed oops
>>  >>>> parameters do not need to be recorded in the archive.
>>  >>>
>>  >>> So you are saying that all klass pointers (references to 
>> klasses) in
>>  >>> metadata structures in metaspace are full.
>>  >>
>>  >> Yes, they are.  (methodOops weren't in the 
>> InstanceKlass::_methods array
>>  >> with Permgen but they are uncompressed now).
>>  >>
>>  >>> And klass pointers are only compressed in java object headers 
>> (which
>>  >>> are not part of CDS). Right?
>>  >>
>>  >> The InstanceKlass has offsets to fields in the instance, and they 
>> depend
>>  >> on both compressed oops and compressed klass pointers.   So both 
>> have to
>>  >> be on for the offsets to be valid.
>>  >>
>>  >> But the base and compressed values are not stored anywhere in the 
>> CDS
>>  >> archive.
>>  >>
>>  >>> And you don't care about UseCompressedOops and
>>  >>> UseCompressedKlassPointers flags settings when you dump it into
>>  >>> archive. The only limit is:
>>  >>>
>>  >>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) - 
>> cds_total
>>  >>>
>>  >>> Then I don't understand why you can't use/load CDS archive when 
>> coop
>>  >>> or compklass are off:
>>  >>>
>>  >>> > If coop is turned off then CDS cannot be used.  CDS will only be
>>  >>> > supported if both UseCompressedOops and 
>> UseCompressedKlassPointers
>>  >>> are
>>  >>> > TRUE.
>>  >>>
>>  >>> Also based on code in arguments.cpp it is allowed to specify
>>  >>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on 
>> command line:
>>  >>>
>>  >>> 1466     // Turn on UseCompressedKlassPointers too
>>  >>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>>  >>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>>  >>> 1469     }
>>  >>>
>>  >>> Did you tested such combination?
>>  >>
>>  >> I should let Harold answer this but I believe this is what his test
>>  >> does.  For CDS on 64 bit, both must be on.   We didn't want to 
>> create 4
>>  >> different archives.   And it wouldn't make too much sense since 
>> CDS for
>>  >> 64 bit is a footprint savings so why would you use it without
>>  >> compressing oops and class pointers?  It's not a startup savings on
>>  >> server because we turn off interpreter bytecode quickening.
>>  >>
>>  >> Coleen
>>  >>
>>  >>>
>>  >>>>>
>>  >>>>> set_narrow_klass_base_and_shift() and
>>  >>>>> can_use_cds_with_metaspace_addr() have the same code for
>>  >>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>  >>>>> can_use_cds_with_metaspace_addr() from
>>  >>>>> set_narrow_klass_base_and_shift() ?
>>  >>>> I could add new inlined methods that determine the 
>> higher_address and
>>  >>>> lower_base when UseSharedSpaces is true and have them called from
>>  >>>> set_narrow_klass_base_and_shift() and
>>  >>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>>  >>>
>>  >>> I tried several approaches but your implementation is more 
>> clean. So I
>>  >>> agree to keep what you have now.
>>  >>>
>>  >>>
>>  >>> Also I found strange assert which should always fail (old code in
>>  >>> global_initialize() in metaspace.cpp):
>>  >>>
>>  >>> 2959     if (UseSharedSpaces) {
>>  >>> ...
>>  >>> 2969       } else {
>>  >>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>>  >>> 2971                "archive file not closed or shared spaces not
>>  >>> disabled.");
>>  >>>
>>  >>> Thanks,
>>  >>> Vladimir
>>  >>>
>>  >>>>>
>>  >>>>> I see that you unconditionally set comp klass ptr base and 
>> shift for
>>  >>>>> DumpSharedSpaces. Should you do the check similar to
>>  >>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>>  >>>>> don't even check UseCompressedKlassPointers.
>>  >>>> I don't think the checks are needed because the information 
>> written to
>>  >>>> the archive is not affected by the size of the class metaspace.
>>  >>>>
>>  >>>> Also, I recently added code to arguments.cpp that will generate an
>>  >>>> error
>>  >>>> if UseCompressedOops or UseCompressedKlassPointers is turned 
>> off and
>>  >>>> DumpSharedSpaces is on.
>>  >>>>>
>>  >>>>> Why you have next limitation? What if coop can't be used 
>> because of
>>  >>>>> big heap?:
>>  >>>>>
>>  >>>>> +     // UseCompressedOops and UseCompressedKlassPointers must 
>> be on
>>  >>>>> for UseSharedSpaces.
>>  >>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>  >>>>> +       no_shared_spaces();
>>  >>>> If coop is turned off then CDS cannot be used.  CDS will only be
>>  >>>> supported if both UseCompressedOops and 
>> UseCompressedKlassPointers are
>>  >>>> TRUE.
>>  >>>>>
>>  >>>>> Could you move UseCompressedKlassPointers code in 
>> arguments.cpp into
>>  >>>>> separate method similar to set_use_compressed_oops()?
>>  >>>> Done.
>>  >>>>>
>>  >>>>> About new tests.
>>  >>>>> The first test in CDSCompressedKPtrsError misses
>>  >>>>> -XX:+UseCompressedOops flag.
>>  >>>> Fixed.
>>  >>>>>
>>  >>>>> Could you also test cross flags combinations?:
>>  >>>>>
>>  >>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>  >>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>  >>>> Done.
>>  >>>>>
>>  >>>>> It would be nice to have test to check ClassMetaspaceSize value
>>  >>>>> range.
>>  >>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither 
>> maxint
>>  >>>>> or maxuint.
>>  >>>> A member of our runtime SQE group is writing additional tests. 
>> I'll
>>  >>>> ask
>>  >>>> him to write a ClassMetaspaceSize range test.
>>  >>>>
>>  >>>> We chose 3Gb because we thought it was a sufficiently large size.
>>  >>>>>
>>  >>>>>
>>  >>>>> About code style, indention. We align next line to 
>> corresponding part
>>  >>>>> of previous line if we need to split a line. And sometimes it is
>>  >>>>> better to keep one long line. I understand some of them were 
>> before
>>  >>>>> your changes but, please, clean up at lest ones you touched.
>>  >>>> Done.
>>  >>>>>
>>  >>>>> Cases in metaspace.cpp:
>>  >>>>>
>>  >>>>> 2263   assert(raw_word_size >= min_size,
>>  >>>>> 2264     err_msg("Should not deallocate dark matter " 
>> SIZE_FORMAT "<"
>>  >>>>> SIZE_FORMAT, word_size, min_size));
>>  >>>>>
>>  >>>>>
>>  >>>>> 2485   if (Metaspace::using_class_space() &&
>>  >>>>> 2486     (Metaspace::class_space_list() != NULL)) {
>>  >>>>>
>>  >>>>>
>>  >>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>  >>>>> 2575 (Metaspace::using_class_space() ?
>>  >>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>>  >>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>  >>>>>
>>  >>>>>
>>  >>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>  >>>>> SIZE_FORMAT ", "
>>  >>>>> 2695 SIZE_FORMAT " small(s) " SIZE_FORMAT
>>  >>>>> ", "
>>  >>>>> 2696 SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>  >>>>> ", "
>>  >>>>> 2697                            "large count " SIZE_FORMAT,
>>  >>>>> 2698              cls_specialized_count, cls_specialized_waste,
>>  >>>>> 2699              cls_small_count, cls_small_waste,
>>  >>>>> 2700              cls_medium_count, cls_medium_waste,
>>  >>>>> cls_humongous_count);
>>  >>>>>
>>  >>>>>
>>  >>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G >
>>  >>>>> addr) &&
>>  >>>>> 2873 can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>  >>>>>
>>  >>>>>
>>  >>>>> 2889 vm_exit_during_initialization(err_msg(
>>  >>>>> 2890           "Could not allocate metaspace: %d bytes",
>>  >>>>> 2891           class_metaspace_size()));
>>  >>>>>
>>  >>>>>
>>  >>>>> 3107     return using_class_space() ?
>>  >>>>> 3108 class_vsm()->sum_used_in_chunks_in_use() : 0;
>>  >>>>>
>>  >>>>>
>>  >>>>> 3157     if (is_class && using_class_space()) {
>>  >>>>> 3158 class_vsm()->deallocate(ptr, word_size);
>>  >>>>>
>>  >>>>>
>>  >>>>> 3305   return space_list()->contains(ptr) ||
>>  >>>>> 3306     (using_class_space() && 
>> class_space_list()->contains(ptr));
>>  >>>>>
>>  >>>>> metaspace.hpp:
>>  >>>>>
>>  >>>>>  270     return 
>> _allocated_capacity_words[Metaspace::NonClassType] +
>>  >>>>>  271       (Metaspace::using_class_space() ?
>>  >>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>>  >>>>>
>>  >>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>>  >>>>>  286       (Metaspace::using_class_space() ?
>>  >>>>>  287 _allocated_used_words[Metaspace::ClassType] : 0);
>>  >>>>>
>>  >>>>> universe.cpp:
>>  >>>>>
>>  >>>>>  849 assert((intptr_t)Universe::narrow_oop_base() <=
>>  >>>>> (intptr_t)(Universe::heap()->base() -
>>  >>>>>  850     os::vm_page_size()) ||
>>  >>>>>  851 Universe::narrow_oop_base() == NULL, "invalid
>>  >>>>> value");
>>  >>>>>
>>  >>>>>
>>  >>>>> Thanks,
>>  >>>>> Vladimir
>>  >>>>>
>>  >>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>  >>>>>> Hi,
>>  >>>>>>
>>  >>>>>> Please review this updated webrev for bug 8003424:
>>  >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>  >>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>  >>>>>>
>>  >>>>>> The updated webrev has a lot of changes from the previous 
>> webrev,
>>  >>>>>> including the following:
>>  >>>>>>
>>  >>>>>>     1. Class metaspace information is now output when
>>  >>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>  >>>>>>
>>  >>>>>>     2. decode_klass_not_null(Register dst, Register src) no 
>> longer
>>  >>>>>>     clobbers R12.
>>  >>>>>>
>>  >>>>>>     3. Method using_class_vsm() was renamed to 
>> using_class_space().
>>  >>>>>>
>>  >>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>>  >>>>>> appropriate.
>>  >>>>>>
>>  >>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>  >>>>>> unnecessary.
>>  >>>>>>
>>  >>>>>>     6. Metaspace::initialize_class_space() was made private.
>>  >>>>>>
>>  >>>>>>     7. Method max_heap_for_compressed_oops(), in 
>> arguments.cpp, was
>>  >>>>>> updated.
>>  >>>>>>
>>  >>>>>> Performance tests were run by Jenny using specjvm2008, 
>> specjbb2005,
>>  >>>>>> and
>>  >>>>>> specjbb2013.  The results showed no significant performance
>>  >>>>>> difference
>>  >>>>>> in terms of scores and gc behavior.
>>  >>>>>>
>>  >>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>>  >>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>  >>>>>>
>>  >>>>>> Please let me know what additional tests should be run.
>>  >>>>>>
>>  >>>>>> Thanks!
>>  >>>>>> Harold
>>  >>>>>>
>>  >>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>  >>>>>>> Hi Harold,
>>  >>>>>>>
>>  >>>>>>> > Usually the narrow_klass_base will be 32G and the
>>  >>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which
>>  >>>>>>> means
>>  >>>>>>> that
>>  >>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will 
>> need R12,
>>  >>>>>>> unless
>>  >>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does 
>> that
>>  >>>>>>> make
>>  >>>>>>> sense?
>>  >>>>>>>
>>  >>>>>>> My bad, I miscalculated. But we have "perfect value" 
>> 0x800000000
>>  >>>>>>> and I
>>  >>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>  >>>>>>> (assuming or
>>  >>>>>>> with check that class metaspace size < 32Gb).
>>  >>>>>>>
>>  >>>>>>> > Is there one prefix byte per instruction, or just for certain
>>  >>>>>>> instructions?
>>  >>>>>>>
>>  >>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>  >>>>>>> prefix is
>>  >>>>>>> necessary only if an instruction references one of the extended
>>  >>>>>>> registers or uses a 64-bit operand."
>>  >>>>>>>
>>  >>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16 
>> and
>>  >>>>>>> =32
>>  >>>>>>> and big java heap. Recently we got several bugs which indicated
>>  >>>>>>> that
>>  >>>>>>> we did not separate cleanly oops and klass pointers 
>> en/decoding.
>>  >>>>>>>
>>  >>>>>>> Thanks,
>>  >>>>>>> Vladimir
>>  >>>>>>>
>>  >>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>  >>>>>>>> Hi Vladimir,
>>  >>>>>>>>
>>  >>>>>>>> Thank you for the review! Please see inline comments.
>>  >>>>>>>>
>>  >>>>>>>> Thanks, Harold
>>  >>>>>>>>
>>  >>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>  >>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>  >>>>>>>>>> Nice clean up, Harold
>>  >>>>>>>>>>
>>  >>>>>>>>>> Could you add the size of class metaspace in output with
>>  >>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>  >>>>>>>>>> remember an
>>  >>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>  >>>>>>>> Will be done in next webrev.
>>  >>>>>>>>>>
>>  >>>>>>>>>> Also it would be nice to print these info line (and 
>> compressed
>>  >>>>>>>>>> oops
>>  >>>>>>>>>> info
>>  >>>>>>>>>> line) in hs_err files.
>>  >>>>>>>> I filed an enhancement bug for this: 8021264
>>  >>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>  >>>>>>>>>>
>>  >>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>>  >>>>>>>>>> x86_64.ad.
>>  >>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use
>>  >>>>>>>>>> arithmetic
>>  >>>>>>>>>> instructions which modify flags: subq, addq, shrq, 
>> xorptr. Also
>>  >>>>>>>>>> note
>>  >>>>>>>>>> that code in .ad file does not check the encoding mode for
>>  >>>>>>>>>> narrow
>>  >>>>>>>>>> klass/oop so it should be conservative and assume that
>>  >>>>>>>>>> arithmetic
>>  >>>>>>>>>> instructions are used.
>>  >>>>>>>> OK. Thanks.
>>  >>>>>>>>>>
>>  >>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass 
>> base below
>>  >>>>>>>>>> 4Gb so
>>  >>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>  >>>>>>>>>> encoding/decoding without destroying R12.
>>  >>>>>>>>>
>>  >>>>>>>>> Correction. You can do it only if base < 2Gb max positive int
>>  >>>>>>>>> (sign
>>  >>>>>>>>> bit is extended so you will get wrong result with address 
>> > 2gb).
>>  >>>>>>>> But the base will normally be 32Gb.  So this case won't happen
>>  >>>>>>>> very
>>  >>>>>>>> often.
>>  >>>>>>>>>
>>  >>>>>>>>> You definitely should not use R12 in
>>  >>>>>>>>> decode_klass_not_null(Register
>>  >>>>>>>>> dst, Register src) method where you have free 'dst' register.
>>  >>>>>>>> Will be fixed in next webrev.
>>  >>>>>>>>>
>>  >>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G). 
>> Actually it
>>  >>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be
>>  >>>>>>>>> 64Gb.
>>  >>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>  >>>>>>>>>
>>  >>>>>>>>> decode:
>>  >>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>  >>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>  >>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>  >>>>>>>>>   }
>>  >>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>  >>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>  >>>>>>>>> }
>>  >>>>>>>>>
>>  >>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>  >>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <=
>>  >>>>>>>>> maxint
>>  >>>>>>>>> (max positive int).
>>  >>>>>>>> Usually the narrow_klass_base will be 32G and the
>>  >>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment) 
>> which means
>>  >>>>>>>> that
>>  >>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need 
>> R12,
>>  >>>>>>>> unless
>>  >>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that
>>  >>>>>>>> make
>>  >>>>>>>> sense?
>>  >>>>>>>>>
>>  >>>>>>>>> And you have general memory reservation problem. At least on
>>  >>>>>>>>> Solaris,
>>  >>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
>>  >>>>>>>>> between
>>  >>>>>>>>> different requested memory regions. That is why in jdk7 we 
>> first
>>  >>>>>>>>> reserve one huge space and then cut it on java heap, perm 
>> gen and
>>  >>>>>>>>> protection page below heap to catch implicit NULL 
>> exceptions with
>>  >>>>>>>>> compressed oops.
>>  >>>>>>>>>
>>  >>>>>>>>> So, please, verify that you are getting 'cds_address + 
>> cds_total'
>>  >>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>  >>>>>>>>> compressed
>>  >>>>>>>>> oops and with Xmx20Gb.
>>  >>>>>>>> I verifed that we get either cds_address+cds_total as the
>>  >>>>>>>> address, or
>>  >>>>>>>> CompressedKlassPointersBase as the address without CDS on 
>> Linux,
>>  >>>>>>>> Windows
>>  >>>>>>>> 7, Mac OS, and Solaris 5.11. This is true with default heap
>>  >>>>>>>> sizes and
>>  >>>>>>>> -Xmx32G.
>>  >>>>>>>>
>>  >>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or 
>> the
>>  >>>>>>>> desired
>>  >>>>>>>> CDS address for class metaspace regardless of heap size.
>>  >>>>>>>>>
>>  >>>>>>>>>>
>>  >>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>  >>>>>>>>>> unfortunately we
>>  >>>>>>>>>> can't do other way. I assume you use max size because
>>  >>>>>>>>>> depending on
>>  >>>>>>>>>> registers used in instructions you will or will not get 
>> prefix
>>  >>>>>>>>>> byte
>>  >>>>>>>>>> (r8-r15).
>>  >>>>>>>> Is there one prefix byte per instruction, or just for certain
>>  >>>>>>>> instructions?
>>  >>>>>>>>>>
>>  >>>>>>>>>> I will look on changes in more details may be late.
>>  >>>>>>>>>
>>  >>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use
>>  >>>>>>>>> abbreviations
>>  >>>>>>>>> which are not obvious.
>>  >>>>>>>> I changed using_class_vsm() to using_class_space().
>>  >>>>>>>>>
>>  >>>>>>>>>
>>  >>>>>>>>>>
>>  >>>>>>>>>> Thanks,
>>  >>>>>>>>>> Vladimir
>>  >>>>>>>>>>
>>  >>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>  >>>>>>>>>>> Hi,
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> Please review this fix for bug 8003424.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> Open webrev at 
>> http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>  >>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>  >>>>>>>>>>> Open bug links at:
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> JBS Bug links at
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>  >>>>>>>>>>>
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> This fix provides support for using compressed klass 
>> pointers
>>  >>>>>>>>>>> with
>>  >>>>>>>>>>> CDS.
>>  >>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>  >>>>>>>>>>> platforms
>>  >>>>>>>>>>> when
>>  >>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of 
>> allocating the
>>  >>>>>>>>>>> class
>>  >>>>>>>>>>> metaspace as part of the Java Heap allocation and locating
>>  >>>>>>>>>>> it at
>>  >>>>>>>>>>> the
>>  >>>>>>>>>>> base of that allocation, the metaspace will now be 
>> allocated
>>  >>>>>>>>>>> separately,
>>  >>>>>>>>>>> above the Java heap.  This will enable future expansion 
>> of the
>>  >>>>>>>>>>> metaspace
>>  >>>>>>>>>>> because it won't be backed up against the Java heap. If 
>> CDS is
>>  >>>>>>>>>>> being
>>  >>>>>>>>>>> used, then the CDS region will be allocated between the 
>> Java
>>  >>>>>>>>>>> heap and
>>  >>>>>>>>>>> the metaspace.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> The new class metaspace allocation code tries to allocate
>>  >>>>>>>>>>> memory at
>>  >>>>>>>>>>> 32G,
>>  >>>>>>>>>>> or above the CDS region, if it is present. Because of this,
>>  >>>>>>>>>>> encoding
>>  >>>>>>>>>>> and decoding of compressed klass pointers will always
>>  >>>>>>>>>>> require use
>>  >>>>>>>>>>> of a
>>  >>>>>>>>>>> base register. So, encoding and decoding of compressed 
>> klass
>>  >>>>>>>>>>> pointers
>>  >>>>>>>>>>> will differ from compressed oops.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> There are no class metaspace allocation changes if
>>  >>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
>>  >>>>>>>>>>> 32-bit
>>  >>>>>>>>>>> platform.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> The code changes also include some cleanup and will fix 
>> bugs
>>  >>>>>>>>>>> 8016729,
>>  >>>>>>>>>>> 8011610, and 8003424.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> Many of the modules in this webrev contain a lot of 
>> changes.
>>  >>>>>>>>>>> Modules
>>  >>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>  >>>>>>>>>>> changed to
>>  >>>>>>>>>>> support the new encoding and decoding of compressed klass
>>  >>>>>>>>>>> pointers.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> Module metaspace.cpp was changed significantly to support
>>  >>>>>>>>>>> the new
>>  >>>>>>>>>>> allocation for metaspace and the CDS region and to 
>> determine
>>  >>>>>>>>>>> compressed
>>  >>>>>>>>>>> klass pointer encoding base and shifting values.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> Most of the changes to module universe.cpp were to 
>> remove code
>>  >>>>>>>>>>> related
>>  >>>>>>>>>>> to allocating metaspace and remove code that considered
>>  >>>>>>>>>>> compressed
>>  >>>>>>>>>>> klass
>>  >>>>>>>>>>> pointers when determining the compressed oops compression
>>  >>>>>>>>>>> mechanism.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as
>>  >>>>>>>>>>> part
>>  >>>>>>>>>>> of a
>>  >>>>>>>>>>> cleanup requested by Coleen.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
>>  >>>>>>>>>>> tests,
>>  >>>>>>>>>>> JPRT,
>>  >>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and
>>  >>>>>>>>>>> vm.mlvm.testlist
>>  >>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and
>>  >>>>>>>>>>> -Xshare:off
>>  >>>>>>>>>>> (with
>>  >>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit
>>  >>>>>>>>>>> Linux and
>>  >>>>>>>>>>> 64-Bit
>>  >>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS. 
>> JCK tests
>>  >>>>>>>>>>> were
>>  >>>>>>>>>>> run on Solaris x86.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> The performance impact of these changes is TBD.
>>  >>>>>>>>>>>
>>  >>>>>>>>>>> Thanks, Harold
>>  >>>>>>>>>>>
>>  >>>>>>>>>>>
>>  >>>>>>>>
>>  >>>>>>
>>  >>>>
>>  >>
>>


From mikael.gerdin at oracle.com  Wed Aug 14 05:21:29 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 14 Aug 2013 14:21:29 +0200
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <520B758C.2080405@oracle.com>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
	<520B4228.7000307@oracle.com> <520B758C.2080405@oracle.com>
Message-ID: <520B7649.6080604@oracle.com>

Harold,

On 2013-08-14 14:18, harold seigel wrote:
> Hi Mikael,
>
> Thanks for the review.
>
> In test CDSCompressedKPtrs.java, RuntimeException gets thrown by
> output.shouldContain(), if it does not find the specified text in the
> test's output.  In this test, it may not find "sharing" in the test
> output if the JVM was unable to compatibly allocate the class
> metaspace.  If the class metaspace does not get allocated near the CDS
> region then the JVM turns off CDS, disabling sharing.  Since this is a
> valid execution path, it shouldn't cause the test to fail.
>
> I've added a comment and changed the test a bit to try and make it clearer:
>
>        } catch (RuntimeException e) {
>          // Report 'passed' if CDS was turned off because we could not
> allocate
>          // the klass metaspace at an address that would work with CDS.
>          output.shouldContain("Could not allocate metaspace at a
> compatible address");
>          output.shouldHaveExitValue(1);
>        }

I see. I suspected that this was the case but it wasn't clear earlier. I 
think that the comment is sufficient to communicate this.


/Mikael

>
> Thanks, Harold
>
> On 8/14/2013 4:39 AM, Mikael Gerdin wrote:
>> Harold,
>>
>> On 2013-08-09 16:57, Harold Seigel wrote:
>>> Hi,
>>>
>>> Please review this latest version of the bug fix for 8003424:
>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/
>>>
>>>
>>> This new version includes the following changes:
>>>
>>> 1. macroAssembler_sparc.cpp
>>>
>>>     a. Merged two versions of reinit_heapbase() into one.
>>>
>>>     b. Improved decode_klass_not_null(src, dst) to not use G6 if
>>> shift == 0.
>>>
>>>
>>> 2. macroAssembler_x86.cpp
>>>
>>>     a. Merged two versions of reinit_heapbase() into one.
>>>
>>>     b. Improved encode_klass_not_null(src, dst) to not use R12.
>>>
>>>     c. Replaced leaq with addq in decode_klass_not_null(src, dst).
>>>
>>>
>>> 3. Improved variable names in heap.cpp.
>>>
>>>
>>> 4. metaspace.cpp
>>>
>>>     a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more
>>> understandable.
>>>
>>>     b. Moved set_narrow_klass_base_and_shift() near
>>> can_use_cds_with_metaspace_addr().
>>>
>>>     c. Changed unneeded conditional in initialize_class_space() into an
>>> assert.
>>>
>>>
>>> 5. arguments.cpp
>>>
>>>     a. Fixed problem with -Xshare:dump and disabled compression.
>>>
>>>     b. Moved UseCompressedKlassPointers code into new function:
>>> set_use_compressed_klass_ptrs().
>>>
>>>     c. Fixed bug 8005933 that turned off CDS for -server even if
>>> -Xshare:auto was explicitly specified.
>>>
>>>
>>> 6. Increased default value of ClassMetaspaceSize to 1*G in globals.hpp.
>>>
>>>
>>> 7. Fixed indentation issues in metaspace.cpp and other modules.
>>
>> The VM changes look good to me.
>>
>> I have a question about the test CDSCompressedKPtrs.java
>>
>> What RuntimeException do you expect and why is it ok that we can't use
>> the shared archive if you get such an exception?
>>
>> I think at least a comment about why the test is supposed to pass even
>> if we can't use the shared archive.
>>
>> /Mikael
>>
>>>
>>>
>>> Thanks, Harold
>>>
>>> ----- Original Message -----
>>> From: harold.seigel at oracle.com
>>> To: coleen.phillimore at oracle.com
>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>> Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern
>>> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
>>> CompressedOops
>>>
>>> The purpose of this assert is to verify that the two methods in the 'if'
>>> clause closed the map file and disabled UseSharedSpaces if they detected
>>> a problem when trying to use CDS.
>>>
>>>        if (mapinfo->initialize() &&
>>> MetaspaceShared::map_shared_spaces(mapinfo)) {
>>>          FileMapInfo::set_current_info(mapinfo);
>>>        } else {
>>>          assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>                 "archive file not closed or shared spaces not
>>> disabled.");
>>>        }
>>>
>>> ----- Original Message -----
>>> From: harold.seigel at oracle.com
>>> To: coleen.phillimore at oracle.com
>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>> Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
>>> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
>>> CompressedOops
>>>
>>> This is a bug that Stefan Karlsson also discovered.  To fix it, I've
>>> changed the code to this:
>>>
>>>    if (DumpSharedSpaces) {
>>>      if (RequireSharedSpaces) {
>>>        warning("cannot dump shared archive while using shared archive");
>>>      }
>>>      UseSharedSpaces = false;
>>> #ifdef _LP64
>>>      if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>        vm_exit_during_initialization(
>>>          "Cannot dump shared archive when UseCompressedOops or
>>> UseCompressedKlassPointers is off.", NULL);
>>>      }
>>>
>>> Harold
>>>
>>>
>>> ----- Original Message -----
>>> From: coleen.phillimore at oracle.com
>>> To: hotspot-runtime-dev at openjdk.java.net
>>> Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
>>> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
>>> CompressedOops
>>>
>>>
>>> Yes, there should be a check for that too.  Now I'll really let Harold
>>> answer.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
>>>  > Coleen, Harold
>>>  >
>>>  > > The InstanceKlass has offsets to fields in the instance, and they
>>>  > depend
>>>  > > on both compressed oops and compressed klass pointers.   So both
>>>  > have to
>>>  > > be on for the offsets to be valid.
>>>  >
>>>  > So there is dependency on UseCompressedOops and
>>>  > UseCompressedKlassPointers flags during dump.
>>>  >
>>>  > Then why the check is done only for UseSharedSpaces and not for
>>>  > DumpSharedSpaces?:
>>>  >
>>>  >     if (DumpSharedSpaces) {
>>>  >       if (RequireSharedSpaces) {
>>>  >         warning("cannot dump shared archive while using shared
>>> archive");
>>>  >       }
>>>  >       UseSharedSpaces = false;
>>>  > + #ifdef _LP64
>>>  > +   } else {
>>>  > +     // UseCompressedOops and UseCompressedKlassPointers must be on
>>>  > for UseSharedSpaces.
>>>  > +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>  > +       no_shared_spaces();
>>>  > +     }
>>>  > + #endif
>>>  >     }
>>>  >
>>>  > Thanks,
>>>  > Vladimir
>>>  >
>>>  > On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>>>  >>
>>>  >> Hi Vladimir,
>>>  >>
>>>  >> I have a couple of answers and I'll let Harold answer the rest.
>>>  >>
>>>  >> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>>>  >>> On 8/7/13 8:34 AM, harold seigel wrote:
>>>  >>>> Hi Vladimir,
>>>  >>>>
>>>  >>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>>  >>>>> Harold,
>>>  >>>>>
>>>  >>>>> Note, on SPARC set() could generate up to 8 instructions to load
>>>  >>>>> 64-bit constant into register. So I am not sure that it will be
>>>  >>>>> faster
>>>  >>>>> than load.
>>>  >>>> We thought it would be faster because it doesn't need to load
>>> anything
>>>  >>>> from memory.
>>>  >>>
>>>  >>> For good value (0x800000000) it should use only 2-3 instructions.
>>>  >>> I think you can keep using set().
>>>  >>>
>>>  >>>>>
>>>  >>>>> I can't find where in CDS you store information about compressed
>>>  >>>>> klass
>>>  >>>>> pointers and compressed oops parameters which were used during
>>> dump?
>>>  >>>>> How you verify that correct parameters/flags are ussed when
>>> such CDS
>>>  >>>>> is used later?
>>>  >>>> No compressed klass pointers nor compressed oops get written to
>>> the
>>>  >>>> archive.  So, the compressed klass pointers and compressed oops
>>>  >>>> parameters do not need to be recorded in the archive.
>>>  >>>
>>>  >>> So you are saying that all klass pointers (references to
>>> klasses) in
>>>  >>> metadata structures in metaspace are full.
>>>  >>
>>>  >> Yes, they are.  (methodOops weren't in the
>>> InstanceKlass::_methods array
>>>  >> with Permgen but they are uncompressed now).
>>>  >>
>>>  >>> And klass pointers are only compressed in java object headers
>>> (which
>>>  >>> are not part of CDS). Right?
>>>  >>
>>>  >> The InstanceKlass has offsets to fields in the instance, and they
>>> depend
>>>  >> on both compressed oops and compressed klass pointers.   So both
>>> have to
>>>  >> be on for the offsets to be valid.
>>>  >>
>>>  >> But the base and compressed values are not stored anywhere in the
>>> CDS
>>>  >> archive.
>>>  >>
>>>  >>> And you don't care about UseCompressedOops and
>>>  >>> UseCompressedKlassPointers flags settings when you dump it into
>>>  >>> archive. The only limit is:
>>>  >>>
>>>  >>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) -
>>> cds_total
>>>  >>>
>>>  >>> Then I don't understand why you can't use/load CDS archive when
>>> coop
>>>  >>> or compklass are off:
>>>  >>>
>>>  >>> > If coop is turned off then CDS cannot be used.  CDS will only be
>>>  >>> > supported if both UseCompressedOops and
>>> UseCompressedKlassPointers
>>>  >>> are
>>>  >>> > TRUE.
>>>  >>>
>>>  >>> Also based on code in arguments.cpp it is allowed to specify
>>>  >>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on
>>> command line:
>>>  >>>
>>>  >>> 1466     // Turn on UseCompressedKlassPointers too
>>>  >>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>>>  >>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>>>  >>> 1469     }
>>>  >>>
>>>  >>> Did you tested such combination?
>>>  >>
>>>  >> I should let Harold answer this but I believe this is what his test
>>>  >> does.  For CDS on 64 bit, both must be on.   We didn't want to
>>> create 4
>>>  >> different archives.   And it wouldn't make too much sense since
>>> CDS for
>>>  >> 64 bit is a footprint savings so why would you use it without
>>>  >> compressing oops and class pointers?  It's not a startup savings on
>>>  >> server because we turn off interpreter bytecode quickening.
>>>  >>
>>>  >> Coleen
>>>  >>
>>>  >>>
>>>  >>>>>
>>>  >>>>> set_narrow_klass_base_and_shift() and
>>>  >>>>> can_use_cds_with_metaspace_addr() have the same code for
>>>  >>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>>  >>>>> can_use_cds_with_metaspace_addr() from
>>>  >>>>> set_narrow_klass_base_and_shift() ?
>>>  >>>> I could add new inlined methods that determine the
>>> higher_address and
>>>  >>>> lower_base when UseSharedSpaces is true and have them called from
>>>  >>>> set_narrow_klass_base_and_shift() and
>>>  >>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>>>  >>>
>>>  >>> I tried several approaches but your implementation is more
>>> clean. So I
>>>  >>> agree to keep what you have now.
>>>  >>>
>>>  >>>
>>>  >>> Also I found strange assert which should always fail (old code in
>>>  >>> global_initialize() in metaspace.cpp):
>>>  >>>
>>>  >>> 2959     if (UseSharedSpaces) {
>>>  >>> ...
>>>  >>> 2969       } else {
>>>  >>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>  >>> 2971                "archive file not closed or shared spaces not
>>>  >>> disabled.");
>>>  >>>
>>>  >>> Thanks,
>>>  >>> Vladimir
>>>  >>>
>>>  >>>>>
>>>  >>>>> I see that you unconditionally set comp klass ptr base and
>>> shift for
>>>  >>>>> DumpSharedSpaces. Should you do the check similar to
>>>  >>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>>>  >>>>> don't even check UseCompressedKlassPointers.
>>>  >>>> I don't think the checks are needed because the information
>>> written to
>>>  >>>> the archive is not affected by the size of the class metaspace.
>>>  >>>>
>>>  >>>> Also, I recently added code to arguments.cpp that will generate an
>>>  >>>> error
>>>  >>>> if UseCompressedOops or UseCompressedKlassPointers is turned
>>> off and
>>>  >>>> DumpSharedSpaces is on.
>>>  >>>>>
>>>  >>>>> Why you have next limitation? What if coop can't be used
>>> because of
>>>  >>>>> big heap?:
>>>  >>>>>
>>>  >>>>> +     // UseCompressedOops and UseCompressedKlassPointers must
>>> be on
>>>  >>>>> for UseSharedSpaces.
>>>  >>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>  >>>>> +       no_shared_spaces();
>>>  >>>> If coop is turned off then CDS cannot be used.  CDS will only be
>>>  >>>> supported if both UseCompressedOops and
>>> UseCompressedKlassPointers are
>>>  >>>> TRUE.
>>>  >>>>>
>>>  >>>>> Could you move UseCompressedKlassPointers code in
>>> arguments.cpp into
>>>  >>>>> separate method similar to set_use_compressed_oops()?
>>>  >>>> Done.
>>>  >>>>>
>>>  >>>>> About new tests.
>>>  >>>>> The first test in CDSCompressedKPtrsError misses
>>>  >>>>> -XX:+UseCompressedOops flag.
>>>  >>>> Fixed.
>>>  >>>>>
>>>  >>>>> Could you also test cross flags combinations?:
>>>  >>>>>
>>>  >>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>>  >>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>>  >>>> Done.
>>>  >>>>>
>>>  >>>>> It would be nice to have test to check ClassMetaspaceSize value
>>>  >>>>> range.
>>>  >>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither
>>> maxint
>>>  >>>>> or maxuint.
>>>  >>>> A member of our runtime SQE group is writing additional tests.
>>> I'll
>>>  >>>> ask
>>>  >>>> him to write a ClassMetaspaceSize range test.
>>>  >>>>
>>>  >>>> We chose 3Gb because we thought it was a sufficiently large size.
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> About code style, indention. We align next line to
>>> corresponding part
>>>  >>>>> of previous line if we need to split a line. And sometimes it is
>>>  >>>>> better to keep one long line. I understand some of them were
>>> before
>>>  >>>>> your changes but, please, clean up at lest ones you touched.
>>>  >>>> Done.
>>>  >>>>>
>>>  >>>>> Cases in metaspace.cpp:
>>>  >>>>>
>>>  >>>>> 2263   assert(raw_word_size >= min_size,
>>>  >>>>> 2264     err_msg("Should not deallocate dark matter "
>>> SIZE_FORMAT "<"
>>>  >>>>> SIZE_FORMAT, word_size, min_size));
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> 2485   if (Metaspace::using_class_space() &&
>>>  >>>>> 2486     (Metaspace::class_space_list() != NULL)) {
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>>  >>>>> 2575 (Metaspace::using_class_space() ?
>>>  >>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>>>  >>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>>  >>>>> SIZE_FORMAT ", "
>>>  >>>>> 2695 SIZE_FORMAT " small(s) " SIZE_FORMAT
>>>  >>>>> ", "
>>>  >>>>> 2696 SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>>  >>>>> ", "
>>>  >>>>> 2697                            "large count " SIZE_FORMAT,
>>>  >>>>> 2698              cls_specialized_count, cls_specialized_waste,
>>>  >>>>> 2699              cls_small_count, cls_small_waste,
>>>  >>>>> 2700              cls_medium_count, cls_medium_waste,
>>>  >>>>> cls_humongous_count);
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G >
>>>  >>>>> addr) &&
>>>  >>>>> 2873 can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> 2889 vm_exit_during_initialization(err_msg(
>>>  >>>>> 2890           "Could not allocate metaspace: %d bytes",
>>>  >>>>> 2891           class_metaspace_size()));
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> 3107     return using_class_space() ?
>>>  >>>>> 3108 class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> 3157     if (is_class && using_class_space()) {
>>>  >>>>> 3158 class_vsm()->deallocate(ptr, word_size);
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> 3305   return space_list()->contains(ptr) ||
>>>  >>>>> 3306     (using_class_space() &&
>>> class_space_list()->contains(ptr));
>>>  >>>>>
>>>  >>>>> metaspace.hpp:
>>>  >>>>>
>>>  >>>>>  270     return
>>> _allocated_capacity_words[Metaspace::NonClassType] +
>>>  >>>>>  271       (Metaspace::using_class_space() ?
>>>  >>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>  >>>>>
>>>  >>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>>>  >>>>>  286       (Metaspace::using_class_space() ?
>>>  >>>>>  287 _allocated_used_words[Metaspace::ClassType] : 0);
>>>  >>>>>
>>>  >>>>> universe.cpp:
>>>  >>>>>
>>>  >>>>>  849 assert((intptr_t)Universe::narrow_oop_base() <=
>>>  >>>>> (intptr_t)(Universe::heap()->base() -
>>>  >>>>>  850     os::vm_page_size()) ||
>>>  >>>>>  851 Universe::narrow_oop_base() == NULL, "invalid
>>>  >>>>> value");
>>>  >>>>>
>>>  >>>>>
>>>  >>>>> Thanks,
>>>  >>>>> Vladimir
>>>  >>>>>
>>>  >>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>  >>>>>> Hi,
>>>  >>>>>>
>>>  >>>>>> Please review this updated webrev for bug 8003424:
>>>  >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>  >>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>  >>>>>>
>>>  >>>>>> The updated webrev has a lot of changes from the previous
>>> webrev,
>>>  >>>>>> including the following:
>>>  >>>>>>
>>>  >>>>>>     1. Class metaspace information is now output when
>>>  >>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>  >>>>>>
>>>  >>>>>>     2. decode_klass_not_null(Register dst, Register src) no
>>> longer
>>>  >>>>>>     clobbers R12.
>>>  >>>>>>
>>>  >>>>>>     3. Method using_class_vsm() was renamed to
>>> using_class_space().
>>>  >>>>>>
>>>  >>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>>>  >>>>>> appropriate.
>>>  >>>>>>
>>>  >>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>>  >>>>>> unnecessary.
>>>  >>>>>>
>>>  >>>>>>     6. Metaspace::initialize_class_space() was made private.
>>>  >>>>>>
>>>  >>>>>>     7. Method max_heap_for_compressed_oops(), in
>>> arguments.cpp, was
>>>  >>>>>> updated.
>>>  >>>>>>
>>>  >>>>>> Performance tests were run by Jenny using specjvm2008,
>>> specjbb2005,
>>>  >>>>>> and
>>>  >>>>>> specjbb2013.  The results showed no significant performance
>>>  >>>>>> difference
>>>  >>>>>> in terms of scores and gc behavior.
>>>  >>>>>>
>>>  >>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>>>  >>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>>  >>>>>>
>>>  >>>>>> Please let me know what additional tests should be run.
>>>  >>>>>>
>>>  >>>>>> Thanks!
>>>  >>>>>> Harold
>>>  >>>>>>
>>>  >>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>  >>>>>>> Hi Harold,
>>>  >>>>>>>
>>>  >>>>>>> > Usually the narrow_klass_base will be 32G and the
>>>  >>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which
>>>  >>>>>>> means
>>>  >>>>>>> that
>>>  >>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will
>>> need R12,
>>>  >>>>>>> unless
>>>  >>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does
>>> that
>>>  >>>>>>> make
>>>  >>>>>>> sense?
>>>  >>>>>>>
>>>  >>>>>>> My bad, I miscalculated. But we have "perfect value"
>>> 0x800000000
>>>  >>>>>>> and I
>>>  >>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>>  >>>>>>> (assuming or
>>>  >>>>>>> with check that class metaspace size < 32Gb).
>>>  >>>>>>>
>>>  >>>>>>> > Is there one prefix byte per instruction, or just for certain
>>>  >>>>>>> instructions?
>>>  >>>>>>>
>>>  >>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>>  >>>>>>> prefix is
>>>  >>>>>>> necessary only if an instruction references one of the extended
>>>  >>>>>>> registers or uses a 64-bit operand."
>>>  >>>>>>>
>>>  >>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16
>>> and
>>>  >>>>>>> =32
>>>  >>>>>>> and big java heap. Recently we got several bugs which indicated
>>>  >>>>>>> that
>>>  >>>>>>> we did not separate cleanly oops and klass pointers
>>> en/decoding.
>>>  >>>>>>>
>>>  >>>>>>> Thanks,
>>>  >>>>>>> Vladimir
>>>  >>>>>>>
>>>  >>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>  >>>>>>>> Hi Vladimir,
>>>  >>>>>>>>
>>>  >>>>>>>> Thank you for the review! Please see inline comments.
>>>  >>>>>>>>
>>>  >>>>>>>> Thanks, Harold
>>>  >>>>>>>>
>>>  >>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>  >>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>  >>>>>>>>>> Nice clean up, Harold
>>>  >>>>>>>>>>
>>>  >>>>>>>>>> Could you add the size of class metaspace in output with
>>>  >>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>  >>>>>>>>>> remember an
>>>  >>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>  >>>>>>>> Will be done in next webrev.
>>>  >>>>>>>>>>
>>>  >>>>>>>>>> Also it would be nice to print these info line (and
>>> compressed
>>>  >>>>>>>>>> oops
>>>  >>>>>>>>>> info
>>>  >>>>>>>>>> line) in hs_err files.
>>>  >>>>>>>> I filed an enhancement bug for this: 8021264
>>>  >>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>  >>>>>>>>>>
>>>  >>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>>>  >>>>>>>>>> x86_64.ad.
>>>  >>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use
>>>  >>>>>>>>>> arithmetic
>>>  >>>>>>>>>> instructions which modify flags: subq, addq, shrq,
>>> xorptr. Also
>>>  >>>>>>>>>> note
>>>  >>>>>>>>>> that code in .ad file does not check the encoding mode for
>>>  >>>>>>>>>> narrow
>>>  >>>>>>>>>> klass/oop so it should be conservative and assume that
>>>  >>>>>>>>>> arithmetic
>>>  >>>>>>>>>> instructions are used.
>>>  >>>>>>>> OK. Thanks.
>>>  >>>>>>>>>>
>>>  >>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass
>>> base below
>>>  >>>>>>>>>> 4Gb so
>>>  >>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>  >>>>>>>>>> encoding/decoding without destroying R12.
>>>  >>>>>>>>>
>>>  >>>>>>>>> Correction. You can do it only if base < 2Gb max positive int
>>>  >>>>>>>>> (sign
>>>  >>>>>>>>> bit is extended so you will get wrong result with address
>>> > 2gb).
>>>  >>>>>>>> But the base will normally be 32Gb.  So this case won't happen
>>>  >>>>>>>> very
>>>  >>>>>>>> often.
>>>  >>>>>>>>>
>>>  >>>>>>>>> You definitely should not use R12 in
>>>  >>>>>>>>> decode_klass_not_null(Register
>>>  >>>>>>>>> dst, Register src) method where you have free 'dst' register.
>>>  >>>>>>>> Will be fixed in next webrev.
>>>  >>>>>>>>>
>>>  >>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G).
>>> Actually it
>>>  >>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be
>>>  >>>>>>>>> 64Gb.
>>>  >>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>  >>>>>>>>>
>>>  >>>>>>>>> decode:
>>>  >>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>  >>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>  >>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>  >>>>>>>>>   }
>>>  >>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>  >>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>  >>>>>>>>> }
>>>  >>>>>>>>>
>>>  >>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>  >>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <=
>>>  >>>>>>>>> maxint
>>>  >>>>>>>>> (max positive int).
>>>  >>>>>>>> Usually the narrow_klass_base will be 32G and the
>>>  >>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment)
>>> which means
>>>  >>>>>>>> that
>>>  >>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need
>>> R12,
>>>  >>>>>>>> unless
>>>  >>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that
>>>  >>>>>>>> make
>>>  >>>>>>>> sense?
>>>  >>>>>>>>>
>>>  >>>>>>>>> And you have general memory reservation problem. At least on
>>>  >>>>>>>>> Solaris,
>>>  >>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
>>>  >>>>>>>>> between
>>>  >>>>>>>>> different requested memory regions. That is why in jdk7 we
>>> first
>>>  >>>>>>>>> reserve one huge space and then cut it on java heap, perm
>>> gen and
>>>  >>>>>>>>> protection page below heap to catch implicit NULL
>>> exceptions with
>>>  >>>>>>>>> compressed oops.
>>>  >>>>>>>>>
>>>  >>>>>>>>> So, please, verify that you are getting 'cds_address +
>>> cds_total'
>>>  >>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>  >>>>>>>>> compressed
>>>  >>>>>>>>> oops and with Xmx20Gb.
>>>  >>>>>>>> I verifed that we get either cds_address+cds_total as the
>>>  >>>>>>>> address, or
>>>  >>>>>>>> CompressedKlassPointersBase as the address without CDS on
>>> Linux,
>>>  >>>>>>>> Windows
>>>  >>>>>>>> 7, Mac OS, and Solaris 5.11. This is true with default heap
>>>  >>>>>>>> sizes and
>>>  >>>>>>>> -Xmx32G.
>>>  >>>>>>>>
>>>  >>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or
>>> the
>>>  >>>>>>>> desired
>>>  >>>>>>>> CDS address for class metaspace regardless of heap size.
>>>  >>>>>>>>>
>>>  >>>>>>>>>>
>>>  >>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>>  >>>>>>>>>> unfortunately we
>>>  >>>>>>>>>> can't do other way. I assume you use max size because
>>>  >>>>>>>>>> depending on
>>>  >>>>>>>>>> registers used in instructions you will or will not get
>>> prefix
>>>  >>>>>>>>>> byte
>>>  >>>>>>>>>> (r8-r15).
>>>  >>>>>>>> Is there one prefix byte per instruction, or just for certain
>>>  >>>>>>>> instructions?
>>>  >>>>>>>>>>
>>>  >>>>>>>>>> I will look on changes in more details may be late.
>>>  >>>>>>>>>
>>>  >>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use
>>>  >>>>>>>>> abbreviations
>>>  >>>>>>>>> which are not obvious.
>>>  >>>>>>>> I changed using_class_vsm() to using_class_space().
>>>  >>>>>>>>>
>>>  >>>>>>>>>
>>>  >>>>>>>>>>
>>>  >>>>>>>>>> Thanks,
>>>  >>>>>>>>>> Vladimir
>>>  >>>>>>>>>>
>>>  >>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>  >>>>>>>>>>> Hi,
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> Please review this fix for bug 8003424.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> Open webrev at
>>> http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>  >>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>  >>>>>>>>>>> Open bug links at:
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> JBS Bug links at
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> This fix provides support for using compressed klass
>>> pointers
>>>  >>>>>>>>>>> with
>>>  >>>>>>>>>>> CDS.
>>>  >>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>>  >>>>>>>>>>> platforms
>>>  >>>>>>>>>>> when
>>>  >>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of
>>> allocating the
>>>  >>>>>>>>>>> class
>>>  >>>>>>>>>>> metaspace as part of the Java Heap allocation and locating
>>>  >>>>>>>>>>> it at
>>>  >>>>>>>>>>> the
>>>  >>>>>>>>>>> base of that allocation, the metaspace will now be
>>> allocated
>>>  >>>>>>>>>>> separately,
>>>  >>>>>>>>>>> above the Java heap.  This will enable future expansion
>>> of the
>>>  >>>>>>>>>>> metaspace
>>>  >>>>>>>>>>> because it won't be backed up against the Java heap. If
>>> CDS is
>>>  >>>>>>>>>>> being
>>>  >>>>>>>>>>> used, then the CDS region will be allocated between the
>>> Java
>>>  >>>>>>>>>>> heap and
>>>  >>>>>>>>>>> the metaspace.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> The new class metaspace allocation code tries to allocate
>>>  >>>>>>>>>>> memory at
>>>  >>>>>>>>>>> 32G,
>>>  >>>>>>>>>>> or above the CDS region, if it is present. Because of this,
>>>  >>>>>>>>>>> encoding
>>>  >>>>>>>>>>> and decoding of compressed klass pointers will always
>>>  >>>>>>>>>>> require use
>>>  >>>>>>>>>>> of a
>>>  >>>>>>>>>>> base register. So, encoding and decoding of compressed
>>> klass
>>>  >>>>>>>>>>> pointers
>>>  >>>>>>>>>>> will differ from compressed oops.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> There are no class metaspace allocation changes if
>>>  >>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
>>>  >>>>>>>>>>> 32-bit
>>>  >>>>>>>>>>> platform.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> The code changes also include some cleanup and will fix
>>> bugs
>>>  >>>>>>>>>>> 8016729,
>>>  >>>>>>>>>>> 8011610, and 8003424.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> Many of the modules in this webrev contain a lot of
>>> changes.
>>>  >>>>>>>>>>> Modules
>>>  >>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>>  >>>>>>>>>>> changed to
>>>  >>>>>>>>>>> support the new encoding and decoding of compressed klass
>>>  >>>>>>>>>>> pointers.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> Module metaspace.cpp was changed significantly to support
>>>  >>>>>>>>>>> the new
>>>  >>>>>>>>>>> allocation for metaspace and the CDS region and to
>>> determine
>>>  >>>>>>>>>>> compressed
>>>  >>>>>>>>>>> klass pointer encoding base and shifting values.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> Most of the changes to module universe.cpp were to
>>> remove code
>>>  >>>>>>>>>>> related
>>>  >>>>>>>>>>> to allocating metaspace and remove code that considered
>>>  >>>>>>>>>>> compressed
>>>  >>>>>>>>>>> klass
>>>  >>>>>>>>>>> pointers when determining the compressed oops compression
>>>  >>>>>>>>>>> mechanism.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as
>>>  >>>>>>>>>>> part
>>>  >>>>>>>>>>> of a
>>>  >>>>>>>>>>> cleanup requested by Coleen.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
>>>  >>>>>>>>>>> tests,
>>>  >>>>>>>>>>> JPRT,
>>>  >>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and
>>>  >>>>>>>>>>> vm.mlvm.testlist
>>>  >>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and
>>>  >>>>>>>>>>> -Xshare:off
>>>  >>>>>>>>>>> (with
>>>  >>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit
>>>  >>>>>>>>>>> Linux and
>>>  >>>>>>>>>>> 64-Bit
>>>  >>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS.
>>> JCK tests
>>>  >>>>>>>>>>> were
>>>  >>>>>>>>>>> run on Solaris x86.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> The performance impact of these changes is TBD.
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>> Thanks, Harold
>>>  >>>>>>>>>>>
>>>  >>>>>>>>>>>
>>>  >>>>>>>>
>>>  >>>>>>
>>>  >>>>
>>>  >>
>>>
>

From harold.seigel at oracle.com  Wed Aug 14 05:21:58 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 14 Aug 2013 08:21:58 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <520B7649.6080604@oracle.com>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
	<520B4228.7000307@oracle.com> <520B758C.2080405@oracle.com>
	<520B7649.6080604@oracle.com>
Message-ID: <520B7666.7070504@oracle.com>

Thanks,
Harold

On 8/14/2013 8:21 AM, Mikael Gerdin wrote:
> Harold,
>
> On 2013-08-14 14:18, harold seigel wrote:
>> Hi Mikael,
>>
>> Thanks for the review.
>>
>> In test CDSCompressedKPtrs.java, RuntimeException gets thrown by
>> output.shouldContain(), if it does not find the specified text in the
>> test's output.  In this test, it may not find "sharing" in the test
>> output if the JVM was unable to compatibly allocate the class
>> metaspace.  If the class metaspace does not get allocated near the CDS
>> region then the JVM turns off CDS, disabling sharing.  Since this is a
>> valid execution path, it shouldn't cause the test to fail.
>>
>> I've added a comment and changed the test a bit to try and make it 
>> clearer:
>>
>>        } catch (RuntimeException e) {
>>          // Report 'passed' if CDS was turned off because we could not
>> allocate
>>          // the klass metaspace at an address that would work with CDS.
>>          output.shouldContain("Could not allocate metaspace at a
>> compatible address");
>>          output.shouldHaveExitValue(1);
>>        }
>
> I see. I suspected that this was the case but it wasn't clear earlier. 
> I think that the comment is sufficient to communicate this.
>
>
> /Mikael
>
>>
>> Thanks, Harold
>>
>> On 8/14/2013 4:39 AM, Mikael Gerdin wrote:
>>> Harold,
>>>
>>> On 2013-08-09 16:57, Harold Seigel wrote:
>>>> Hi,
>>>>
>>>> Please review this latest version of the bug fix for 8003424:
>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/
>>>>
>>>>
>>>> This new version includes the following changes:
>>>>
>>>> 1. macroAssembler_sparc.cpp
>>>>
>>>>     a. Merged two versions of reinit_heapbase() into one.
>>>>
>>>>     b. Improved decode_klass_not_null(src, dst) to not use G6 if
>>>> shift == 0.
>>>>
>>>>
>>>> 2. macroAssembler_x86.cpp
>>>>
>>>>     a. Merged two versions of reinit_heapbase() into one.
>>>>
>>>>     b. Improved encode_klass_not_null(src, dst) to not use R12.
>>>>
>>>>     c. Replaced leaq with addq in decode_klass_not_null(src, dst).
>>>>
>>>>
>>>> 3. Improved variable names in heap.cpp.
>>>>
>>>>
>>>> 4. metaspace.cpp
>>>>
>>>>     a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more
>>>> understandable.
>>>>
>>>>     b. Moved set_narrow_klass_base_and_shift() near
>>>> can_use_cds_with_metaspace_addr().
>>>>
>>>>     c. Changed unneeded conditional in initialize_class_space() 
>>>> into an
>>>> assert.
>>>>
>>>>
>>>> 5. arguments.cpp
>>>>
>>>>     a. Fixed problem with -Xshare:dump and disabled compression.
>>>>
>>>>     b. Moved UseCompressedKlassPointers code into new function:
>>>> set_use_compressed_klass_ptrs().
>>>>
>>>>     c. Fixed bug 8005933 that turned off CDS for -server even if
>>>> -Xshare:auto was explicitly specified.
>>>>
>>>>
>>>> 6. Increased default value of ClassMetaspaceSize to 1*G in 
>>>> globals.hpp.
>>>>
>>>>
>>>> 7. Fixed indentation issues in metaspace.cpp and other modules.
>>>
>>> The VM changes look good to me.
>>>
>>> I have a question about the test CDSCompressedKPtrs.java
>>>
>>> What RuntimeException do you expect and why is it ok that we can't use
>>> the shared archive if you get such an exception?
>>>
>>> I think at least a comment about why the test is supposed to pass even
>>> if we can't use the shared archive.
>>>
>>> /Mikael
>>>
>>>>
>>>>
>>>> Thanks, Harold
>>>>
>>>> ----- Original Message -----
>>>> From: harold.seigel at oracle.com
>>>> To: coleen.phillimore at oracle.com
>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>> Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern
>>>> Subject: Re: Request for review: 8003424 - Enable Class Data 
>>>> Sharing for
>>>> CompressedOops
>>>>
>>>> The purpose of this assert is to verify that the two methods in the 
>>>> 'if'
>>>> clause closed the map file and disabled UseSharedSpaces if they 
>>>> detected
>>>> a problem when trying to use CDS.
>>>>
>>>>        if (mapinfo->initialize() &&
>>>> MetaspaceShared::map_shared_spaces(mapinfo)) {
>>>>          FileMapInfo::set_current_info(mapinfo);
>>>>        } else {
>>>>          assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>>                 "archive file not closed or shared spaces not
>>>> disabled.");
>>>>        }
>>>>
>>>> ----- Original Message -----
>>>> From: harold.seigel at oracle.com
>>>> To: coleen.phillimore at oracle.com
>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>> Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
>>>> Subject: Re: Request for review: 8003424 - Enable Class Data 
>>>> Sharing for
>>>> CompressedOops
>>>>
>>>> This is a bug that Stefan Karlsson also discovered.  To fix it, I've
>>>> changed the code to this:
>>>>
>>>>    if (DumpSharedSpaces) {
>>>>      if (RequireSharedSpaces) {
>>>>        warning("cannot dump shared archive while using shared 
>>>> archive");
>>>>      }
>>>>      UseSharedSpaces = false;
>>>> #ifdef _LP64
>>>>      if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>        vm_exit_during_initialization(
>>>>          "Cannot dump shared archive when UseCompressedOops or
>>>> UseCompressedKlassPointers is off.", NULL);
>>>>      }
>>>>
>>>> Harold
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: coleen.phillimore at oracle.com
>>>> To: hotspot-runtime-dev at openjdk.java.net
>>>> Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
>>>> Subject: Re: Request for review: 8003424 - Enable Class Data 
>>>> Sharing for
>>>> CompressedOops
>>>>
>>>>
>>>> Yes, there should be a check for that too.  Now I'll really let Harold
>>>> answer.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
>>>>  > Coleen, Harold
>>>>  >
>>>>  > > The InstanceKlass has offsets to fields in the instance, and they
>>>>  > depend
>>>>  > > on both compressed oops and compressed klass pointers.   So both
>>>>  > have to
>>>>  > > be on for the offsets to be valid.
>>>>  >
>>>>  > So there is dependency on UseCompressedOops and
>>>>  > UseCompressedKlassPointers flags during dump.
>>>>  >
>>>>  > Then why the check is done only for UseSharedSpaces and not for
>>>>  > DumpSharedSpaces?:
>>>>  >
>>>>  >     if (DumpSharedSpaces) {
>>>>  >       if (RequireSharedSpaces) {
>>>>  >         warning("cannot dump shared archive while using shared
>>>> archive");
>>>>  >       }
>>>>  >       UseSharedSpaces = false;
>>>>  > + #ifdef _LP64
>>>>  > +   } else {
>>>>  > +     // UseCompressedOops and UseCompressedKlassPointers must 
>>>> be on
>>>>  > for UseSharedSpaces.
>>>>  > +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>  > +       no_shared_spaces();
>>>>  > +     }
>>>>  > + #endif
>>>>  >     }
>>>>  >
>>>>  > Thanks,
>>>>  > Vladimir
>>>>  >
>>>>  > On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>>>>  >>
>>>>  >> Hi Vladimir,
>>>>  >>
>>>>  >> I have a couple of answers and I'll let Harold answer the rest.
>>>>  >>
>>>>  >> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>>>>  >>> On 8/7/13 8:34 AM, harold seigel wrote:
>>>>  >>>> Hi Vladimir,
>>>>  >>>>
>>>>  >>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>>>  >>>>> Harold,
>>>>  >>>>>
>>>>  >>>>> Note, on SPARC set() could generate up to 8 instructions to 
>>>> load
>>>>  >>>>> 64-bit constant into register. So I am not sure that it will be
>>>>  >>>>> faster
>>>>  >>>>> than load.
>>>>  >>>> We thought it would be faster because it doesn't need to load
>>>> anything
>>>>  >>>> from memory.
>>>>  >>>
>>>>  >>> For good value (0x800000000) it should use only 2-3 instructions.
>>>>  >>> I think you can keep using set().
>>>>  >>>
>>>>  >>>>>
>>>>  >>>>> I can't find where in CDS you store information about 
>>>> compressed
>>>>  >>>>> klass
>>>>  >>>>> pointers and compressed oops parameters which were used during
>>>> dump?
>>>>  >>>>> How you verify that correct parameters/flags are ussed when
>>>> such CDS
>>>>  >>>>> is used later?
>>>>  >>>> No compressed klass pointers nor compressed oops get written to
>>>> the
>>>>  >>>> archive.  So, the compressed klass pointers and compressed oops
>>>>  >>>> parameters do not need to be recorded in the archive.
>>>>  >>>
>>>>  >>> So you are saying that all klass pointers (references to
>>>> klasses) in
>>>>  >>> metadata structures in metaspace are full.
>>>>  >>
>>>>  >> Yes, they are.  (methodOops weren't in the
>>>> InstanceKlass::_methods array
>>>>  >> with Permgen but they are uncompressed now).
>>>>  >>
>>>>  >>> And klass pointers are only compressed in java object headers
>>>> (which
>>>>  >>> are not part of CDS). Right?
>>>>  >>
>>>>  >> The InstanceKlass has offsets to fields in the instance, and they
>>>> depend
>>>>  >> on both compressed oops and compressed klass pointers.   So both
>>>> have to
>>>>  >> be on for the offsets to be valid.
>>>>  >>
>>>>  >> But the base and compressed values are not stored anywhere in the
>>>> CDS
>>>>  >> archive.
>>>>  >>
>>>>  >>> And you don't care about UseCompressedOops and
>>>>  >>> UseCompressedKlassPointers flags settings when you dump it into
>>>>  >>> archive. The only limit is:
>>>>  >>>
>>>>  >>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) -
>>>> cds_total
>>>>  >>>
>>>>  >>> Then I don't understand why you can't use/load CDS archive when
>>>> coop
>>>>  >>> or compklass are off:
>>>>  >>>
>>>>  >>> > If coop is turned off then CDS cannot be used.  CDS will 
>>>> only be
>>>>  >>> > supported if both UseCompressedOops and
>>>> UseCompressedKlassPointers
>>>>  >>> are
>>>>  >>> > TRUE.
>>>>  >>>
>>>>  >>> Also based on code in arguments.cpp it is allowed to specify
>>>>  >>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on
>>>> command line:
>>>>  >>>
>>>>  >>> 1466     // Turn on UseCompressedKlassPointers too
>>>>  >>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>>>>  >>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>>>>  >>> 1469     }
>>>>  >>>
>>>>  >>> Did you tested such combination?
>>>>  >>
>>>>  >> I should let Harold answer this but I believe this is what his 
>>>> test
>>>>  >> does.  For CDS on 64 bit, both must be on.   We didn't want to
>>>> create 4
>>>>  >> different archives.   And it wouldn't make too much sense since
>>>> CDS for
>>>>  >> 64 bit is a footprint savings so why would you use it without
>>>>  >> compressing oops and class pointers?  It's not a startup 
>>>> savings on
>>>>  >> server because we turn off interpreter bytecode quickening.
>>>>  >>
>>>>  >> Coleen
>>>>  >>
>>>>  >>>
>>>>  >>>>>
>>>>  >>>>> set_narrow_klass_base_and_shift() and
>>>>  >>>>> can_use_cds_with_metaspace_addr() have the same code for
>>>>  >>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>>>  >>>>> can_use_cds_with_metaspace_addr() from
>>>>  >>>>> set_narrow_klass_base_and_shift() ?
>>>>  >>>> I could add new inlined methods that determine the
>>>> higher_address and
>>>>  >>>> lower_base when UseSharedSpaces is true and have them called 
>>>> from
>>>>  >>>> set_narrow_klass_base_and_shift() and
>>>>  >>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>>>>  >>>
>>>>  >>> I tried several approaches but your implementation is more
>>>> clean. So I
>>>>  >>> agree to keep what you have now.
>>>>  >>>
>>>>  >>>
>>>>  >>> Also I found strange assert which should always fail (old code in
>>>>  >>> global_initialize() in metaspace.cpp):
>>>>  >>>
>>>>  >>> 2959     if (UseSharedSpaces) {
>>>>  >>> ...
>>>>  >>> 2969       } else {
>>>>  >>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>>  >>> 2971                "archive file not closed or shared spaces not
>>>>  >>> disabled.");
>>>>  >>>
>>>>  >>> Thanks,
>>>>  >>> Vladimir
>>>>  >>>
>>>>  >>>>>
>>>>  >>>>> I see that you unconditionally set comp klass ptr base and
>>>> shift for
>>>>  >>>>> DumpSharedSpaces. Should you do the check similar to
>>>>  >>>>> can_use_cds_with_metaspace_addr() to find if you can do 
>>>> that? You
>>>>  >>>>> don't even check UseCompressedKlassPointers.
>>>>  >>>> I don't think the checks are needed because the information
>>>> written to
>>>>  >>>> the archive is not affected by the size of the class metaspace.
>>>>  >>>>
>>>>  >>>> Also, I recently added code to arguments.cpp that will 
>>>> generate an
>>>>  >>>> error
>>>>  >>>> if UseCompressedOops or UseCompressedKlassPointers is turned
>>>> off and
>>>>  >>>> DumpSharedSpaces is on.
>>>>  >>>>>
>>>>  >>>>> Why you have next limitation? What if coop can't be used
>>>> because of
>>>>  >>>>> big heap?:
>>>>  >>>>>
>>>>  >>>>> +     // UseCompressedOops and UseCompressedKlassPointers must
>>>> be on
>>>>  >>>>> for UseSharedSpaces.
>>>>  >>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>  >>>>> +       no_shared_spaces();
>>>>  >>>> If coop is turned off then CDS cannot be used.  CDS will only be
>>>>  >>>> supported if both UseCompressedOops and
>>>> UseCompressedKlassPointers are
>>>>  >>>> TRUE.
>>>>  >>>>>
>>>>  >>>>> Could you move UseCompressedKlassPointers code in
>>>> arguments.cpp into
>>>>  >>>>> separate method similar to set_use_compressed_oops()?
>>>>  >>>> Done.
>>>>  >>>>>
>>>>  >>>>> About new tests.
>>>>  >>>>> The first test in CDSCompressedKPtrsError misses
>>>>  >>>>> -XX:+UseCompressedOops flag.
>>>>  >>>> Fixed.
>>>>  >>>>>
>>>>  >>>>> Could you also test cross flags combinations?:
>>>>  >>>>>
>>>>  >>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>>>  >>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>>>  >>>> Done.
>>>>  >>>>>
>>>>  >>>>> It would be nice to have test to check ClassMetaspaceSize value
>>>>  >>>>> range.
>>>>  >>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither
>>>> maxint
>>>>  >>>>> or maxuint.
>>>>  >>>> A member of our runtime SQE group is writing additional tests.
>>>> I'll
>>>>  >>>> ask
>>>>  >>>> him to write a ClassMetaspaceSize range test.
>>>>  >>>>
>>>>  >>>> We chose 3Gb because we thought it was a sufficiently large 
>>>> size.
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> About code style, indention. We align next line to
>>>> corresponding part
>>>>  >>>>> of previous line if we need to split a line. And sometimes 
>>>> it is
>>>>  >>>>> better to keep one long line. I understand some of them were
>>>> before
>>>>  >>>>> your changes but, please, clean up at lest ones you touched.
>>>>  >>>> Done.
>>>>  >>>>>
>>>>  >>>>> Cases in metaspace.cpp:
>>>>  >>>>>
>>>>  >>>>> 2263   assert(raw_word_size >= min_size,
>>>>  >>>>> 2264     err_msg("Should not deallocate dark matter "
>>>> SIZE_FORMAT "<"
>>>>  >>>>> SIZE_FORMAT, word_size, min_size));
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2485   if (Metaspace::using_class_space() &&
>>>>  >>>>> 2486 (Metaspace::class_space_list() != NULL)) {
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>>>  >>>>> 2575 (Metaspace::using_class_space() ?
>>>>  >>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 
>>>> 0) :
>>>>  >>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>>>  >>>>> SIZE_FORMAT ", "
>>>>  >>>>> 2695 SIZE_FORMAT " small(s) " SIZE_FORMAT
>>>>  >>>>> ", "
>>>>  >>>>> 2696 SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>>>  >>>>> ", "
>>>>  >>>>> 2697                            "large count " SIZE_FORMAT,
>>>>  >>>>> 2698 cls_specialized_count, cls_specialized_waste,
>>>>  >>>>> 2699              cls_small_count, cls_small_waste,
>>>>  >>>>> 2700              cls_medium_count, cls_medium_waste,
>>>>  >>>>> cls_humongous_count);
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G >
>>>>  >>>>> addr) &&
>>>>  >>>>> 2873 can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2889 vm_exit_during_initialization(err_msg(
>>>>  >>>>> 2890           "Could not allocate metaspace: %d bytes",
>>>>  >>>>> 2891 class_metaspace_size()));
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 3107     return using_class_space() ?
>>>>  >>>>> 3108 class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 3157     if (is_class && using_class_space()) {
>>>>  >>>>> 3158 class_vsm()->deallocate(ptr, word_size);
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 3305   return space_list()->contains(ptr) ||
>>>>  >>>>> 3306     (using_class_space() &&
>>>> class_space_list()->contains(ptr));
>>>>  >>>>>
>>>>  >>>>> metaspace.hpp:
>>>>  >>>>>
>>>>  >>>>>  270     return
>>>> _allocated_capacity_words[Metaspace::NonClassType] +
>>>>  >>>>>  271 (Metaspace::using_class_space() ?
>>>>  >>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>>  >>>>>
>>>>  >>>>>  285     return 
>>>> _allocated_used_words[Metaspace::NonClassType] +
>>>>  >>>>>  286 (Metaspace::using_class_space() ?
>>>>  >>>>>  287 _allocated_used_words[Metaspace::ClassType] : 0);
>>>>  >>>>>
>>>>  >>>>> universe.cpp:
>>>>  >>>>>
>>>>  >>>>>  849 assert((intptr_t)Universe::narrow_oop_base() <=
>>>>  >>>>> (intptr_t)(Universe::heap()->base() -
>>>>  >>>>>  850     os::vm_page_size()) ||
>>>>  >>>>>  851 Universe::narrow_oop_base() == NULL, "invalid
>>>>  >>>>> value");
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> Thanks,
>>>>  >>>>> Vladimir
>>>>  >>>>>
>>>>  >>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>>  >>>>>> Hi,
>>>>  >>>>>>
>>>>  >>>>>> Please review this updated webrev for bug 8003424:
>>>>  >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>>  >>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>  >>>>>>
>>>>  >>>>>> The updated webrev has a lot of changes from the previous
>>>> webrev,
>>>>  >>>>>> including the following:
>>>>  >>>>>>
>>>>  >>>>>>     1. Class metaspace information is now output when
>>>>  >>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>>  >>>>>>
>>>>  >>>>>>     2. decode_klass_not_null(Register dst, Register src) no
>>>> longer
>>>>  >>>>>>     clobbers R12.
>>>>  >>>>>>
>>>>  >>>>>>     3. Method using_class_vsm() was renamed to
>>>> using_class_space().
>>>>  >>>>>>
>>>>  >>>>>>     4. Type narrowKlass was added and replaces narrowOop, 
>>>> where
>>>>  >>>>>> appropriate.
>>>>  >>>>>>
>>>>  >>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>>>  >>>>>> unnecessary.
>>>>  >>>>>>
>>>>  >>>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>  >>>>>>
>>>>  >>>>>>     7. Method max_heap_for_compressed_oops(), in
>>>> arguments.cpp, was
>>>>  >>>>>> updated.
>>>>  >>>>>>
>>>>  >>>>>> Performance tests were run by Jenny using specjvm2008,
>>>> specjbb2005,
>>>>  >>>>>> and
>>>>  >>>>>> specjbb2013.  The results showed no significant performance
>>>>  >>>>>> difference
>>>>  >>>>>> in terms of scores and gc behavior.
>>>>  >>>>>>
>>>>  >>>>>> Additional testing was done on Solaris Sparc and Linux x86 
>>>> using
>>>>  >>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 
>>>> & 32.
>>>>  >>>>>>
>>>>  >>>>>> Please let me know what additional tests should be run.
>>>>  >>>>>>
>>>>  >>>>>> Thanks!
>>>>  >>>>>> Harold
>>>>  >>>>>>
>>>>  >>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>  >>>>>>> Hi Harold,
>>>>  >>>>>>>
>>>>  >>>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>  >>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) 
>>>> which
>>>>  >>>>>>> means
>>>>  >>>>>>> that
>>>>  >>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will
>>>> need R12,
>>>>  >>>>>>> unless
>>>>  >>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does
>>>> that
>>>>  >>>>>>> make
>>>>  >>>>>>> sense?
>>>>  >>>>>>>
>>>>  >>>>>>> My bad, I miscalculated. But we have "perfect value"
>>>> 0x800000000
>>>>  >>>>>>> and I
>>>>  >>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>>>  >>>>>>> (assuming or
>>>>  >>>>>>> with check that class metaspace size < 32Gb).
>>>>  >>>>>>>
>>>>  >>>>>>> > Is there one prefix byte per instruction, or just for 
>>>> certain
>>>>  >>>>>>> instructions?
>>>>  >>>>>>>
>>>>  >>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>>>  >>>>>>> prefix is
>>>>  >>>>>>> necessary only if an instruction references one of the 
>>>> extended
>>>>  >>>>>>> registers or uses a 64-bit operand."
>>>>  >>>>>>>
>>>>  >>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16
>>>> and
>>>>  >>>>>>> =32
>>>>  >>>>>>> and big java heap. Recently we got several bugs which 
>>>> indicated
>>>>  >>>>>>> that
>>>>  >>>>>>> we did not separate cleanly oops and klass pointers
>>>> en/decoding.
>>>>  >>>>>>>
>>>>  >>>>>>> Thanks,
>>>>  >>>>>>> Vladimir
>>>>  >>>>>>>
>>>>  >>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>  >>>>>>>> Hi Vladimir,
>>>>  >>>>>>>>
>>>>  >>>>>>>> Thank you for the review! Please see inline comments.
>>>>  >>>>>>>>
>>>>  >>>>>>>> Thanks, Harold
>>>>  >>>>>>>>
>>>>  >>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>  >>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>  >>>>>>>>>> Nice clean up, Harold
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> Could you add the size of class metaspace in output with
>>>>  >>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't 
>>>> want to
>>>>  >>>>>>>>>> remember an
>>>>  >>>>>>>>>> other very long flag name: 
>>>> TraceMetavirtualspaceAllocation.
>>>>  >>>>>>>> Will be done in next webrev.
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> Also it would be nice to print these info line (and
>>>> compressed
>>>>  >>>>>>>>>> oops
>>>>  >>>>>>>>>> info
>>>>  >>>>>>>>>> line) in hs_err files.
>>>>  >>>>>>>> I filed an enhancement bug for this: 8021264
>>>>  >>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL 
>>>> needed?" in
>>>>  >>>>>>>>>> x86_64.ad.
>>>>  >>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use
>>>>  >>>>>>>>>> arithmetic
>>>>  >>>>>>>>>> instructions which modify flags: subq, addq, shrq,
>>>> xorptr. Also
>>>>  >>>>>>>>>> note
>>>>  >>>>>>>>>> that code in .ad file does not check the encoding mode for
>>>>  >>>>>>>>>> narrow
>>>>  >>>>>>>>>> klass/oop so it should be conservative and assume that
>>>>  >>>>>>>>>> arithmetic
>>>>  >>>>>>>>>> instructions are used.
>>>>  >>>>>>>> OK. Thanks.
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass
>>>> base below
>>>>  >>>>>>>>>> 4Gb so
>>>>  >>>>>>>>>> the value is 32 bit. You can use it directly in narrow 
>>>> klass
>>>>  >>>>>>>>>> encoding/decoding without destroying R12.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> Correction. You can do it only if base < 2Gb max 
>>>> positive int
>>>>  >>>>>>>>> (sign
>>>>  >>>>>>>>> bit is extended so you will get wrong result with address
>>>> > 2gb).
>>>>  >>>>>>>> But the base will normally be 32Gb.  So this case won't 
>>>> happen
>>>>  >>>>>>>> very
>>>>  >>>>>>>> often.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> You definitely should not use R12 in
>>>>  >>>>>>>>> decode_klass_not_null(Register
>>>>  >>>>>>>>> dst, Register src) method where you have free 'dst' 
>>>> register.
>>>>  >>>>>>>> Will be fixed in next webrev.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G).
>>>> Actually it
>>>>  >>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it 
>>>> should be
>>>>  >>>>>>>>> 64Gb.
>>>>  >>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> decode:
>>>>  >>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>  >>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>  >>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>  >>>>>>>>>   }
>>>>  >>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>  >>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>  >>>>>>>>> }
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>  >>>>>>>>> (Universe::narrow_klass_base >> 
>>>> LogKlassAlignmentInBytes) <=
>>>>  >>>>>>>>> maxint
>>>>  >>>>>>>>> (max positive int).
>>>>  >>>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>  >>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment)
>>>> which means
>>>>  >>>>>>>> that
>>>>  >>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need
>>>> R12,
>>>>  >>>>>>>> unless
>>>>  >>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does 
>>>> that
>>>>  >>>>>>>> make
>>>>  >>>>>>>> sense?
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> And you have general memory reservation problem. At 
>>>> least on
>>>>  >>>>>>>>> Solaris,
>>>>  >>>>>>>>> as I remember, OS will always try to keep protected 4Kb 
>>>> pages
>>>>  >>>>>>>>> between
>>>>  >>>>>>>>> different requested memory regions. That is why in jdk7 we
>>>> first
>>>>  >>>>>>>>> reserve one huge space and then cut it on java heap, perm
>>>> gen and
>>>>  >>>>>>>>> protection page below heap to catch implicit NULL
>>>> exceptions with
>>>>  >>>>>>>>> compressed oops.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> So, please, verify that you are getting 'cds_address +
>>>> cds_total'
>>>>  >>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>>  >>>>>>>>> compressed
>>>>  >>>>>>>>> oops and with Xmx20Gb.
>>>>  >>>>>>>> I verifed that we get either cds_address+cds_total as the
>>>>  >>>>>>>> address, or
>>>>  >>>>>>>> CompressedKlassPointersBase as the address without CDS on
>>>> Linux,
>>>>  >>>>>>>> Windows
>>>>  >>>>>>>> 7, Mac OS, and Solaris 5.11. This is true with default heap
>>>>  >>>>>>>> sizes and
>>>>  >>>>>>>> -Xmx32G.
>>>>  >>>>>>>>
>>>>  >>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or
>>>> the
>>>>  >>>>>>>> desired
>>>>  >>>>>>>> CDS address for class metaspace regardless of heap size.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>>>  >>>>>>>>>> unfortunately we
>>>>  >>>>>>>>>> can't do other way. I assume you use max size because
>>>>  >>>>>>>>>> depending on
>>>>  >>>>>>>>>> registers used in instructions you will or will not get
>>>> prefix
>>>>  >>>>>>>>>> byte
>>>>  >>>>>>>>>> (r8-r15).
>>>>  >>>>>>>> Is there one prefix byte per instruction, or just for 
>>>> certain
>>>>  >>>>>>>> instructions?
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> I will look on changes in more details may be late.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use
>>>>  >>>>>>>>> abbreviations
>>>>  >>>>>>>>> which are not obvious.
>>>>  >>>>>>>> I changed using_class_vsm() to using_class_space().
>>>>  >>>>>>>>>
>>>>  >>>>>>>>>
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> Thanks,
>>>>  >>>>>>>>>> Vladimir
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>  >>>>>>>>>>> Hi,
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Please review this fix for bug 8003424.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Open webrev at
>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>  >>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>  >>>>>>>>>>> Open bug links at:
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> JBS Bug links at
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> This fix provides support for using compressed klass
>>>> pointers
>>>>  >>>>>>>>>>> with
>>>>  >>>>>>>>>>> CDS.
>>>>  >>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>>>  >>>>>>>>>>> platforms
>>>>  >>>>>>>>>>> when
>>>>  >>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of
>>>> allocating the
>>>>  >>>>>>>>>>> class
>>>>  >>>>>>>>>>> metaspace as part of the Java Heap allocation and 
>>>> locating
>>>>  >>>>>>>>>>> it at
>>>>  >>>>>>>>>>> the
>>>>  >>>>>>>>>>> base of that allocation, the metaspace will now be
>>>> allocated
>>>>  >>>>>>>>>>> separately,
>>>>  >>>>>>>>>>> above the Java heap.  This will enable future expansion
>>>> of the
>>>>  >>>>>>>>>>> metaspace
>>>>  >>>>>>>>>>> because it won't be backed up against the Java heap. If
>>>> CDS is
>>>>  >>>>>>>>>>> being
>>>>  >>>>>>>>>>> used, then the CDS region will be allocated between the
>>>> Java
>>>>  >>>>>>>>>>> heap and
>>>>  >>>>>>>>>>> the metaspace.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> The new class metaspace allocation code tries to allocate
>>>>  >>>>>>>>>>> memory at
>>>>  >>>>>>>>>>> 32G,
>>>>  >>>>>>>>>>> or above the CDS region, if it is present. Because of 
>>>> this,
>>>>  >>>>>>>>>>> encoding
>>>>  >>>>>>>>>>> and decoding of compressed klass pointers will always
>>>>  >>>>>>>>>>> require use
>>>>  >>>>>>>>>>> of a
>>>>  >>>>>>>>>>> base register. So, encoding and decoding of compressed
>>>> klass
>>>>  >>>>>>>>>>> pointers
>>>>  >>>>>>>>>>> will differ from compressed oops.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> There are no class metaspace allocation changes if
>>>>  >>>>>>>>>>> UseCompressedKlassPointers is turned off or if running 
>>>> on a
>>>>  >>>>>>>>>>> 32-bit
>>>>  >>>>>>>>>>> platform.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> The code changes also include some cleanup and will fix
>>>> bugs
>>>>  >>>>>>>>>>> 8016729,
>>>>  >>>>>>>>>>> 8011610, and 8003424.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Many of the modules in this webrev contain a lot of
>>>> changes.
>>>>  >>>>>>>>>>> Modules
>>>>  >>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>>>  >>>>>>>>>>> changed to
>>>>  >>>>>>>>>>> support the new encoding and decoding of compressed klass
>>>>  >>>>>>>>>>> pointers.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Module metaspace.cpp was changed significantly to support
>>>>  >>>>>>>>>>> the new
>>>>  >>>>>>>>>>> allocation for metaspace and the CDS region and to
>>>> determine
>>>>  >>>>>>>>>>> compressed
>>>>  >>>>>>>>>>> klass pointer encoding base and shifting values.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Most of the changes to module universe.cpp were to
>>>> remove code
>>>>  >>>>>>>>>>> related
>>>>  >>>>>>>>>>> to allocating metaspace and remove code that considered
>>>>  >>>>>>>>>>> compressed
>>>>  >>>>>>>>>>> klass
>>>>  >>>>>>>>>>> pointers when determining the compressed oops compression
>>>>  >>>>>>>>>>> mechanism.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were 
>>>> changed as
>>>>  >>>>>>>>>>> part
>>>>  >>>>>>>>>>> of a
>>>>  >>>>>>>>>>> cleanup requested by Coleen.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> These changes were tested with JCK Lang and VM tests, 
>>>> JTReg
>>>>  >>>>>>>>>>> tests,
>>>>  >>>>>>>>>>> JPRT,
>>>>  >>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and
>>>>  >>>>>>>>>>> vm.mlvm.testlist
>>>>  >>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and
>>>>  >>>>>>>>>>> -Xshare:off
>>>>  >>>>>>>>>>> (with
>>>>  >>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit
>>>>  >>>>>>>>>>> Linux and
>>>>  >>>>>>>>>>> 64-Bit
>>>>  >>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS.
>>>> JCK tests
>>>>  >>>>>>>>>>> were
>>>>  >>>>>>>>>>> run on Solaris x86.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> The performance impact of these changes is TBD.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Thanks, Harold
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>
>>>>  >>>>>>
>>>>  >>>>
>>>>  >>
>>>>
>>


From erik.helin at oracle.com  Wed Aug 14 07:49:06 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 14 Aug 2013 16:49:06 +0200
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass space
Message-ID: <20130814144906.GC2649@ehelin-thinkpad>

Hi all,

this change adds performance counters for compressed class space.

Webrev:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/

Changes to hotspot:
The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
where the class MetaspaceCounters has been split up into
MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
an instance of MetaspacePerfCounters. The class
CompressedClassSpaceCounters has been added which also has its own
instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
updates the actual performance counters.

The changes in metaspace.hpp/cpp were needed to get some additional data
from the metaspace data structures. The method
free_chunks_in_total(mdtype) was made public and the method
free_bytes(mdtype) was added. Some common functionality was extracted
into get_space_list(mdtype) which got rid of some duplicated code.

The changes in:
- g1MonitorinSupport.cpp
- parallelScavengeHeap.cpp
- genCollectedHeap.cpp
- universe.cpp
are only "one-liners" that either update or initialize the new performance
counters.

Changes to the testlibrary:
- Added Asserts.java for writing asserts like "assertTrue",
  "assertEquals", etc.
- Added PerfCounter.java and PerfCounters.java to make it easy to
  inspect performance counters for the currently running VM.
- Added InputArguments.java so a test can check the arguments it got
  passed.
- Added InMemoryJavaCompiler.java for compiling a string into bytecode.
  Useful for loading classes generated at runtime without using files.
- Added ByteCodeLoader.java for defining a new class when you already
  have the bytecode.

Testing:
- Added the new test TestMetaspacePerfCounters.java
- JPRT

Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659

Thanks,
Erik

From ron.durbin at oracle.com  Wed Aug 14 09:49:08 2013
From: ron.durbin at oracle.com (Ron Durbin)
Date: Wed, 14 Aug 2013 09:49:08 -0700 (PDT)
Subject: JDK-8005073 open code review, (round 0)
In-Reply-To: <520ADE08.9010600@oracle.com>
References: <095a82a5-052e-447a-96b5-86e146566366@default>
	<520ADE08.9010600@oracle.com>
Message-ID: <ed2eeebd-3455-40f6-bc50-a6e8dc19742f@default>

Thx for reviewing this change.

> -----Original Message-----
> From: Daniel D. Daugherty
> Sent: Tuesday, August 13, 2013 7:32 PM
> To: Ron Durbin
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: JDK-8005073 open code review, (round 0)
> 
> On 8/13/13 5:42 PM, Ron Durbin wrote:
> > JDK-8005073 [TESTBUG] remove crufty '_g' support from HS tests
> >
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005073
> >
> > Summary:
> >
> > Remove all support and references to '_g' from all open test files.
> >
> > OpenJDK URL:  http://cr.openjdk.java.net/~rdurbin/8005073_open_webrev/
> >
> > Testing so far has included:
> >
> > JPRT all platforms
> >
> 
> test/Makefile
>      No comments.
> 
> Thumbs up.
> 
> Dan
> 

From ron.durbin at oracle.com  Wed Aug 14 09:49:56 2013
From: ron.durbin at oracle.com (Ron Durbin)
Date: Wed, 14 Aug 2013 09:49:56 -0700 (PDT)
Subject: JDK-8005073 open code review, (round 0)
In-Reply-To: <25198B11-0FEA-4A97-832B-ED023FF2E5D5@oracle.com>
References: <095a82a5-052e-447a-96b5-86e146566366@default>
	<25198B11-0FEA-4A97-832B-ED023FF2E5D5@oracle.com>
Message-ID: <21d7a227-222a-4e94-a0cc-f4bb45c3549d@default>

Thanks for reviewing this change.

> -----Original Message-----
> From: Staffan Larsen
> Sent: Wednesday, August 14, 2013 5:53 AM
> To: Ron Durbin
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: JDK-8005073 open code review, (round 0)
> 
> Looks good!
> 
> /Staffan
> 
> On 14 aug 2013, at 01:42, Ron Durbin <ron.durbin at oracle.com> wrote:
> 
> > JDK-8005073 [TESTBUG] remove crufty '_g' support from HS tests
> >
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005073
> >
> > Summary:
> >
> > Remove all support and references to '_g' from all open test files.
> >
> > OpenJDK URL:  http://cr.openjdk.java.net/~rdurbin/8005073_open_webrev/
> >
> > Testing so far has included:
> >
> > JPRT all platforms
> >
> 

From coleen.phillimore at oracle.com  Wed Aug 14 11:11:40 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 14 Aug 2013 14:11:40 -0400
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <20130814144906.GC2649@ehelin-thinkpad>
References: <20130814144906.GC2649@ehelin-thinkpad>
Message-ID: <520BC85C.1010109@oracle.com>


Erik,

I didn't review the test code but the product code looks good, except 
that after Harold's change there won't be a compressed class space 
allocated if !UseCompressedKlassPointers.  It appears that you allocate 
a performance counter for the compressed class space, but don't fill it 
in if !UseCompressedKlassPointers.   The code in metaspace.cpp assumes 
that a class_space_list() returns non-null, so that works now but won't 
(soon, I hope).   Can you write the code to still work if 
class_space_list() returns null because otherwise there's going to be a 
merge conflict that hg won't detect.   lines 2564 and 2571.

Thanks,
Coleen

On 8/14/2013 10:49 AM, Erik Helin wrote:
> Hi all,
>
> this change adds performance counters for compressed class space.
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
>
> Changes to hotspot:
> The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
> where the class MetaspaceCounters has been split up into
> MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
> an instance of MetaspacePerfCounters. The class
> CompressedClassSpaceCounters has been added which also has its own
> instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
> updates the actual performance counters.
>
> The changes in metaspace.hpp/cpp were needed to get some additional data
> from the metaspace data structures. The method
> free_chunks_in_total(mdtype) was made public and the method
> free_bytes(mdtype) was added. Some common functionality was extracted
> into get_space_list(mdtype) which got rid of some duplicated code.
>
> The changes in:
> - g1MonitorinSupport.cpp
> - parallelScavengeHeap.cpp
> - genCollectedHeap.cpp
> - universe.cpp
> are only "one-liners" that either update or initialize the new performance
> counters.
>
> Changes to the testlibrary:
> - Added Asserts.java for writing asserts like "assertTrue",
>    "assertEquals", etc.
> - Added PerfCounter.java and PerfCounters.java to make it easy to
>    inspect performance counters for the currently running VM.
> - Added InputArguments.java so a test can check the arguments it got
>    passed.
> - Added InMemoryJavaCompiler.java for compiling a string into bytecode.
>    Useful for loading classes generated at runtime without using files.
> - Added ByteCodeLoader.java for defining a new class when you already
>    have the bytecode.
>
> Testing:
> - Added the new test TestMetaspacePerfCounters.java
> - JPRT
>
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
>
> Thanks,
> Erik


From ioi.lam at oracle.com  Wed Aug 14 15:11:49 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 14 Aug 2013 15:11:49 -0700
Subject: RFR (S) 8022335 - Native stack walk while generating hs_err does
	not work on Windows x64
Message-ID: <520C00A5.5070306@oracle.com>

|Please review this fix:||
||
||http://cr.openjdk.java.net/~iklam/8022335/win64_stack_walk_001/||
||
||Bug: Native stack walk while generating hs_err does not work on 
Windows x64||
||
||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022335||
||    https://jbs.oracle.com/bugs/browse/JDK-8022335||
||
||Summary of fix:||
||
||    Windows x64 binaries are built (unconditionally) with the 
equivalent of ||
||    -fomit-frame-pointer, so HotSpot's build-in native stack walking 
code ||
||    will fail to find the sender frame. As a result, hs_err on 
Windows/x64||
||    will always list a single frame.||
||
||    I have added the NATIVE_UNWIND_MARK macro, which on Windows/x64 
will invoke||
||    the StackWalk64 API to walk the stace.||
||
||Deficiency of fix:||
||
||    StackWalk64 knows nothing about the Java frames. So hs_err will 
display only||
||    the native frames, and stop as soon as the first Java frame is 
reached. It will||
||    also NOT display any native frames below Java frames.||
||
||    A 'proper' implementation would be to use the the lower-level API ||
||    SymFunctionTableAccess64 (which reads native frame linkage info 
from the PE32+||
||    file header). That way we can walk both the native and Java 
frames. However, ||
||    as noted in the bug report, this is more complex and I will leave it||
||    for the future.||
||
||    As a side-fix, I also refactored a bunch of duplicated code in 
decoder.cpp into||
||    the DecoderLocker class.||
||
||Tests:||
||
||    JPRT||
||    UTE (vm.runtime.testlist, vm.quick.testlist, 
vm.parallel_class_loading.testlist)||
||
||    I also manually inserted some crashes into jvm.dll and verified 
that the ||
||    native stack trace is printed as expected.||
||
||
||Thanks||
||- Ioi||
||
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130814/bb2a4a1f/attachment.html 

From vladimir.kozlov at oracle.com  Wed Aug 14 16:24:54 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 Aug 2013 16:24:54 -0700
Subject: RFR (S) 8022335 - Native stack walk while generating hs_err does
	not work on Windows x64
In-Reply-To: <520C00A5.5070306@oracle.com>
References: <520C00A5.5070306@oracle.com>
Message-ID: <520C11C6.9010707@oracle.com>

For your information I am pushing next related changes:

http://cr.openjdk.java.net/~kvn/8021898/webrev/src/share/vm/utilities/vmError.cpp.cdiff.html

Vladimir

On 8/14/13 3:11 PM, Ioi Lam wrote:
> |Please review this fix:||
> ||
> ||http://cr.openjdk.java.net/~iklam/8022335/win64_stack_walk_001/||
> ||
> ||Bug: Native stack walk while generating hs_err does not work on
> Windows x64||
> ||
> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022335||
> ||https://jbs.oracle.com/bugs/browse/JDK-8022335||
> ||
> ||Summary of fix:||
> ||
> ||    Windows x64 binaries are built (unconditionally) with the
> equivalent of ||
> ||    -fomit-frame-pointer, so HotSpot's build-in native stack walking
> code ||
> ||    will fail to find the sender frame. As a result, hs_err on
> Windows/x64||
> ||    will always list a single frame.||
> ||
> ||    I have added the NATIVE_UNWIND_MARK macro, which on Windows/x64
> will invoke||
> ||    the StackWalk64 API to walk the stace.||
> ||
> ||Deficiency of fix:||
> ||
> ||    StackWalk64 knows nothing about the Java frames. So hs_err will
> display only||
> ||    the native frames, and stop as soon as the first Java frame is
> reached. It will||
> ||    also NOT display any native frames below Java frames.||
> ||
> ||    A 'proper' implementation would be to use the the lower-level API ||
> ||    SymFunctionTableAccess64 (which reads native frame linkage info
> from the PE32+||
> ||    file header). That way we can walk both the native and Java
> frames. However, ||
> ||    as noted in the bug report, this is more complex and I will leave it||
> ||    for the future.||
> ||
> ||    As a side-fix, I also refactored a bunch of duplicated code in
> decoder.cpp into||
> ||    the DecoderLocker class.||
> ||
> ||Tests:||
> ||
> ||    JPRT||
> ||    UTE (vm.runtime.testlist, vm.quick.testlist,
> vm.parallel_class_loading.testlist)||
> ||
> ||    I also manually inserted some crashes into jvm.dll and verified
> that the ||
> ||    native stack trace is printed as expected.||
> ||
> ||
> ||Thanks||
> ||- Ioi||
> ||
> |

From ioi.lam at oracle.com  Wed Aug 14 16:48:28 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 14 Aug 2013 16:48:28 -0700
Subject: RFR (S) 8022335 - Native stack walk while generating hs_err does
	not work on Windows x64
In-Reply-To: <520C11C6.9010707@oracle.com>
References: <520C00A5.5070306@oracle.com> <520C11C6.9010707@oracle.com>
Message-ID: <520C174C.5010808@oracle.com>

Thanks Vladimir,

I will wait for your commit and test with it.

- Ioi

On 08/14/2013 04:24 PM, Vladimir Kozlov wrote:
> For your information I am pushing next related changes:
>
> http://cr.openjdk.java.net/~kvn/8021898/webrev/src/share/vm/utilities/vmError.cpp.cdiff.html 
>
>
> Vladimir
>
> On 8/14/13 3:11 PM, Ioi Lam wrote:
>> |Please review this fix:||
>> ||
>> ||http://cr.openjdk.java.net/~iklam/8022335/win64_stack_walk_001/||
>> ||
>> ||Bug: Native stack walk while generating hs_err does not work on
>> Windows x64||
>> ||
>> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022335||
>> ||https://jbs.oracle.com/bugs/browse/JDK-8022335||
>> ||
>> ||Summary of fix:||
>> ||
>> ||    Windows x64 binaries are built (unconditionally) with the
>> equivalent of ||
>> ||    -fomit-frame-pointer, so HotSpot's build-in native stack walking
>> code ||
>> ||    will fail to find the sender frame. As a result, hs_err on
>> Windows/x64||
>> ||    will always list a single frame.||
>> ||
>> ||    I have added the NATIVE_UNWIND_MARK macro, which on Windows/x64
>> will invoke||
>> ||    the StackWalk64 API to walk the stace.||
>> ||
>> ||Deficiency of fix:||
>> ||
>> ||    StackWalk64 knows nothing about the Java frames. So hs_err will
>> display only||
>> ||    the native frames, and stop as soon as the first Java frame is
>> reached. It will||
>> ||    also NOT display any native frames below Java frames.||
>> ||
>> ||    A 'proper' implementation would be to use the the lower-level 
>> API ||
>> ||    SymFunctionTableAccess64 (which reads native frame linkage info
>> from the PE32+||
>> ||    file header). That way we can walk both the native and Java
>> frames. However, ||
>> ||    as noted in the bug report, this is more complex and I will 
>> leave it||
>> ||    for the future.||
>> ||
>> ||    As a side-fix, I also refactored a bunch of duplicated code in
>> decoder.cpp into||
>> ||    the DecoderLocker class.||
>> ||
>> ||Tests:||
>> ||
>> ||    JPRT||
>> ||    UTE (vm.runtime.testlist, vm.quick.testlist,
>> vm.parallel_class_loading.testlist)||
>> ||
>> ||    I also manually inserted some crashes into jvm.dll and verified
>> that the ||
>> ||    native stack trace is printed as expected.||
>> ||
>> ||
>> ||Thanks||
>> ||- Ioi||
>> ||
>> |


From daniel.daugherty at oracle.com  Wed Aug 14 23:04:06 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Thu, 15 Aug 2013 06:04:06 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8005073: [TESTBUG] remove crufty '_g'
	support from HS tests
Message-ID: <20130815060410.EA68F488B4@hg.openjdk.java.net>

Changeset: d96f52012aaa
Author:    rdurbin
Date:      2013-08-14 15:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d96f52012aaa

8005073: [TESTBUG] remove crufty '_g' support from HS tests
Summary: remove crufty '_g' support from HS tests
Reviewed-by: dcubed, sla

! test/Makefile


From erik.helin at oracle.com  Thu Aug 15 02:20:01 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 15 Aug 2013 11:20:01 +0200
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <520BC85C.1010109@oracle.com>
References: <20130814144906.GC2649@ehelin-thinkpad>
	<520BC85C.1010109@oracle.com>
Message-ID: <20130815092001.GA3750@ehelin-thinkpad>

(Adding hotspot-gc-dev at openjdk.java.net)

Hi Coleen,

thanks for the review!

On 2013-08-14, Coleen Phillimore wrote:
> 
> Erik,
> 
> I didn't review the test code but the product code looks good,
> except that after Harold's change there won't be a compressed class
> space allocated if !UseCompressedKlassPointers.  It appears that you
> allocate a performance counter for the compressed class space, but
> don't fill it in if !UseCompressedKlassPointers.   The code in
> metaspace.cpp assumes that a class_space_list() returns non-null, so
> that works now but won't (soon, I hope).   Can you write the code to
> still work if class_space_list() returns null because otherwise
> there's going to be a merge conflict that hg won't detect.   lines
> 2564 and 2571.

Sure, thanks for reminding me of Harold's change.

I've uploaded a new webrev at:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.01/

For the difference between webrev.00 and webrev.01, please see:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/

Thanks,
Erik

> 
> Thanks,
> Coleen
> 
> On 8/14/2013 10:49 AM, Erik Helin wrote:
> >Hi all,
> >
> >this change adds performance counters for compressed class space.
> >
> >Webrev:
> >http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
> >
> >Changes to hotspot:
> >The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
> >where the class MetaspaceCounters has been split up into
> >MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
> >an instance of MetaspacePerfCounters. The class
> >CompressedClassSpaceCounters has been added which also has its own
> >instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
> >updates the actual performance counters.
> >
> >The changes in metaspace.hpp/cpp were needed to get some additional data
> >from the metaspace data structures. The method
> >free_chunks_in_total(mdtype) was made public and the method
> >free_bytes(mdtype) was added. Some common functionality was extracted
> >into get_space_list(mdtype) which got rid of some duplicated code.
> >
> >The changes in:
> >- g1MonitorinSupport.cpp
> >- parallelScavengeHeap.cpp
> >- genCollectedHeap.cpp
> >- universe.cpp
> >are only "one-liners" that either update or initialize the new performance
> >counters.
> >
> >Changes to the testlibrary:
> >- Added Asserts.java for writing asserts like "assertTrue",
> >   "assertEquals", etc.
> >- Added PerfCounter.java and PerfCounters.java to make it easy to
> >   inspect performance counters for the currently running VM.
> >- Added InputArguments.java so a test can check the arguments it got
> >   passed.
> >- Added InMemoryJavaCompiler.java for compiling a string into bytecode.
> >   Useful for loading classes generated at runtime without using files.
> >- Added ByteCodeLoader.java for defining a new class when you already
> >   have the bytecode.
> >
> >Testing:
> >- Added the new test TestMetaspacePerfCounters.java
> >- JPRT
> >
> >Bug:
> >http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
> >
> >Thanks,
> >Erik
> 

From david.holmes at oracle.com  Thu Aug 15 03:01:44 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Aug 2013 20:01:44 +1000
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <20130814144906.GC2649@ehelin-thinkpad>
References: <20130814144906.GC2649@ehelin-thinkpad>
Message-ID: <520CA708.4090309@oracle.com>

Hi Erik,

Can you add -XX:+UsePerfData to the @run for all tests that require 
UsePerfData to be true (most I expect). This will let the new tests play 
nicely with the Embedded builds.

Thanks,
David


On 15/08/2013 12:49 AM, Erik Helin wrote:
> Hi all,
>
> this change adds performance counters for compressed class space.
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
>
> Changes to hotspot:
> The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
> where the class MetaspaceCounters has been split up into
> MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
> an instance of MetaspacePerfCounters. The class
> CompressedClassSpaceCounters has been added which also has its own
> instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
> updates the actual performance counters.
>
> The changes in metaspace.hpp/cpp were needed to get some additional data
> from the metaspace data structures. The method
> free_chunks_in_total(mdtype) was made public and the method
> free_bytes(mdtype) was added. Some common functionality was extracted
> into get_space_list(mdtype) which got rid of some duplicated code.
>
> The changes in:
> - g1MonitorinSupport.cpp
> - parallelScavengeHeap.cpp
> - genCollectedHeap.cpp
> - universe.cpp
> are only "one-liners" that either update or initialize the new performance
> counters.
>
> Changes to the testlibrary:
> - Added Asserts.java for writing asserts like "assertTrue",
>    "assertEquals", etc.
> - Added PerfCounter.java and PerfCounters.java to make it easy to
>    inspect performance counters for the currently running VM.
> - Added InputArguments.java so a test can check the arguments it got
>    passed.
> - Added InMemoryJavaCompiler.java for compiling a string into bytecode.
>    Useful for loading classes generated at runtime without using files.
> - Added ByteCodeLoader.java for defining a new class when you already
>    have the bytecode.
>
> Testing:
> - Added the new test TestMetaspacePerfCounters.java
> - JPRT
>
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
>
> Thanks,
> Erik
>

From erik.helin at oracle.com  Thu Aug 15 04:32:58 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 15 Aug 2013 13:32:58 +0200
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <520CA708.4090309@oracle.com>
References: <20130814144906.GC2649@ehelin-thinkpad>
	<520CA708.4090309@oracle.com>
Message-ID: <20130815113258.GB3750@ehelin-thinkpad>

Hi David,

thanks for reviewing!

On 2013-08-15, David Holmes wrote:
> Hi Erik,
> 
> Can you add -XX:+UsePerfData to the @run for all tests that require
> UsePerfData to be true (most I expect).

Sure, please see new webrev at:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.02/

For the changes from webrev.00, please see:
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/

Thanks,
Erik

> This will let the new tests play nicely with the Embedded builds.
> 
> Thanks,
> David
> 
> 
> On 15/08/2013 12:49 AM, Erik Helin wrote:
> >Hi all,
> >
> >this change adds performance counters for compressed class space.
> >
> >Webrev:
> >http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
> >
> >Changes to hotspot:
> >The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
> >where the class MetaspaceCounters has been split up into
> >MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
> >an instance of MetaspacePerfCounters. The class
> >CompressedClassSpaceCounters has been added which also has its own
> >instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
> >updates the actual performance counters.
> >
> >The changes in metaspace.hpp/cpp were needed to get some additional data
> >from the metaspace data structures. The method
> >free_chunks_in_total(mdtype) was made public and the method
> >free_bytes(mdtype) was added. Some common functionality was extracted
> >into get_space_list(mdtype) which got rid of some duplicated code.
> >
> >The changes in:
> >- g1MonitorinSupport.cpp
> >- parallelScavengeHeap.cpp
> >- genCollectedHeap.cpp
> >- universe.cpp
> >are only "one-liners" that either update or initialize the new performance
> >counters.
> >
> >Changes to the testlibrary:
> >- Added Asserts.java for writing asserts like "assertTrue",
> >   "assertEquals", etc.
> >- Added PerfCounter.java and PerfCounters.java to make it easy to
> >   inspect performance counters for the currently running VM.
> >- Added InputArguments.java so a test can check the arguments it got
> >   passed.
> >- Added InMemoryJavaCompiler.java for compiling a string into bytecode.
> >   Useful for loading classes generated at runtime without using files.
> >- Added ByteCodeLoader.java for defining a new class when you already
> >   have the bytecode.
> >
> >Testing:
> >- Added the new test TestMetaspacePerfCounters.java
> >- JPRT
> >
> >Bug:
> >http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
> >
> >Thanks,
> >Erik
> >

From david.holmes at oracle.com  Thu Aug 15 04:38:23 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Aug 2013 21:38:23 +1000
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <20130815113258.GB3750@ehelin-thinkpad>
References: <20130814144906.GC2649@ehelin-thinkpad>
	<520CA708.4090309@oracle.com>
	<20130815113258.GB3750@ehelin-thinkpad>
Message-ID: <520CBDAF.6080803@oracle.com>

On 15/08/2013 9:32 PM, Erik Helin wrote:
> Hi David,
>
> thanks for reviewing!

Sorry not a review, I only glanced at the tests.

> On 2013-08-15, David Holmes wrote:
>> Hi Erik,
>>
>> Can you add -XX:+UsePerfData to the @run for all tests that require
>> UsePerfData to be true (most I expect).
>
> Sure, please see new webrev at:
> http://cr.openjdk.java.net/~ehelin/8014659/webrev.02/

Thanks!

David
-----

> For the changes from webrev.00, please see:
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/
>
> Thanks,
> Erik
>
>> This will let the new tests play nicely with the Embedded builds.
>>
>> Thanks,
>> David
>>
>>
>> On 15/08/2013 12:49 AM, Erik Helin wrote:
>>> Hi all,
>>>
>>> this change adds performance counters for compressed class space.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
>>>
>>> Changes to hotspot:
>>> The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
>>> where the class MetaspaceCounters has been split up into
>>> MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
>>> an instance of MetaspacePerfCounters. The class
>>> CompressedClassSpaceCounters has been added which also has its own
>>> instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
>>> updates the actual performance counters.
>>>
>>> The changes in metaspace.hpp/cpp were needed to get some additional data
>> >from the metaspace data structures. The method
>>> free_chunks_in_total(mdtype) was made public and the method
>>> free_bytes(mdtype) was added. Some common functionality was extracted
>>> into get_space_list(mdtype) which got rid of some duplicated code.
>>>
>>> The changes in:
>>> - g1MonitorinSupport.cpp
>>> - parallelScavengeHeap.cpp
>>> - genCollectedHeap.cpp
>>> - universe.cpp
>>> are only "one-liners" that either update or initialize the new performance
>>> counters.
>>>
>>> Changes to the testlibrary:
>>> - Added Asserts.java for writing asserts like "assertTrue",
>>>    "assertEquals", etc.
>>> - Added PerfCounter.java and PerfCounters.java to make it easy to
>>>    inspect performance counters for the currently running VM.
>>> - Added InputArguments.java so a test can check the arguments it got
>>>    passed.
>>> - Added InMemoryJavaCompiler.java for compiling a string into bytecode.
>>>    Useful for loading classes generated at runtime without using files.
>>> - Added ByteCodeLoader.java for defining a new class when you already
>>>    have the bytecode.
>>>
>>> Testing:
>>> - Added the new test TestMetaspacePerfCounters.java
>>> - JPRT
>>>
>>> Bug:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
>>>
>>> Thanks,
>>> Erik
>>>

From erik.helin at oracle.com  Thu Aug 15 04:56:23 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 15 Aug 2013 13:56:23 +0200
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <520CBDAF.6080803@oracle.com>
References: <20130814144906.GC2649@ehelin-thinkpad>
	<520CA708.4090309@oracle.com>
	<20130815113258.GB3750@ehelin-thinkpad>
	<520CBDAF.6080803@oracle.com>
Message-ID: <20130815115623.GC3750@ehelin-thinkpad>

On 2013-08-15, David Holmes wrote:
> On 15/08/2013 9:32 PM, Erik Helin wrote:
> >Hi David,
> >
> >thanks for reviewing!
> 
> Sorry not a review, I only glanced at the tests.

Ok, but thanks for having a look :)

Erik

> >On 2013-08-15, David Holmes wrote:
> >>Hi Erik,
> >>
> >>Can you add -XX:+UsePerfData to the @run for all tests that require
> >>UsePerfData to be true (most I expect).
> >
> >Sure, please see new webrev at:
> >http://cr.openjdk.java.net/~ehelin/8014659/webrev.02/
> 
> Thanks!
> 
> David
> -----
> 
> >For the changes from webrev.00, please see:
> >- http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/
> >- http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/
> >
> >Thanks,
> >Erik
> >
> >>This will let the new tests play nicely with the Embedded builds.
> >>
> >>Thanks,
> >>David
> >>
> >>
> >>On 15/08/2013 12:49 AM, Erik Helin wrote:
> >>>Hi all,
> >>>
> >>>this change adds performance counters for compressed class space.
> >>>
> >>>Webrev:
> >>>http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
> >>>
> >>>Changes to hotspot:
> >>>The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
> >>>where the class MetaspaceCounters has been split up into
> >>>MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
> >>>an instance of MetaspacePerfCounters. The class
> >>>CompressedClassSpaceCounters has been added which also has its own
> >>>instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
> >>>updates the actual performance counters.
> >>>
> >>>The changes in metaspace.hpp/cpp were needed to get some additional data
> >>>from the metaspace data structures. The method
> >>>free_chunks_in_total(mdtype) was made public and the method
> >>>free_bytes(mdtype) was added. Some common functionality was extracted
> >>>into get_space_list(mdtype) which got rid of some duplicated code.
> >>>
> >>>The changes in:
> >>>- g1MonitorinSupport.cpp
> >>>- parallelScavengeHeap.cpp
> >>>- genCollectedHeap.cpp
> >>>- universe.cpp
> >>>are only "one-liners" that either update or initialize the new performance
> >>>counters.
> >>>
> >>>Changes to the testlibrary:
> >>>- Added Asserts.java for writing asserts like "assertTrue",
> >>>   "assertEquals", etc.
> >>>- Added PerfCounter.java and PerfCounters.java to make it easy to
> >>>   inspect performance counters for the currently running VM.
> >>>- Added InputArguments.java so a test can check the arguments it got
> >>>   passed.
> >>>- Added InMemoryJavaCompiler.java for compiling a string into bytecode.
> >>>   Useful for loading classes generated at runtime without using files.
> >>>- Added ByteCodeLoader.java for defining a new class when you already
> >>>   have the bytecode.
> >>>
> >>>Testing:
> >>>- Added the new test TestMetaspacePerfCounters.java
> >>>- JPRT
> >>>
> >>>Bug:
> >>>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
> >>>
> >>>Thanks,
> >>>Erik
> >>>

From christian.tornqvist at oracle.com  Thu Aug 15 06:34:51 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 15 Aug 2013 09:34:51 -0400
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <20130814144906.GC2649@ehelin-thinkpad>
References: <20130814144906.GC2649@ehelin-thinkpad>
Message-ID: <011301ce99bc$38b747c0$aa25d740$@oracle.com>

Hi Erik,

First of all, I've only reviewed the test part of this change. Please add a
small test for the Asserts class, this would make it a lot easier to
fix/change it in the future. Otherwise I think the change looks good, thanks
for adding Asserts and the other classes to testlibrary collection :)

Thanks,
Christian

-----Original Message-----
From: hotspot-runtime-dev-bounces at openjdk.java.net
[mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Erik
Helin
Sent: Wednesday, August 14, 2013 10:49 AM
To: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
space

Hi all,

this change adds performance counters for compressed class space.

Webrev:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/

Changes to hotspot:
The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
where the class MetaspaceCounters has been split up into MetaspaceCounters
and MetaspacePerfCounters. MetaspaceCounters now owns an instance of
MetaspacePerfCounters. The class CompressedClassSpaceCounters has been added
which also has its own instance of MetaspacePerfCounters.
MetaspacePerfCounters initializes and updates the actual performance
counters.

The changes in metaspace.hpp/cpp were needed to get some additional data
from the metaspace data structures. The method
free_chunks_in_total(mdtype) was made public and the method
free_bytes(mdtype) was added. Some common functionality was extracted into
get_space_list(mdtype) which got rid of some duplicated code.

The changes in:
- g1MonitorinSupport.cpp
- parallelScavengeHeap.cpp
- genCollectedHeap.cpp
- universe.cpp
are only "one-liners" that either update or initialize the new performance
counters.

Changes to the testlibrary:
- Added Asserts.java for writing asserts like "assertTrue",
  "assertEquals", etc.
- Added PerfCounter.java and PerfCounters.java to make it easy to
  inspect performance counters for the currently running VM.
- Added InputArguments.java so a test can check the arguments it got
  passed.
- Added InMemoryJavaCompiler.java for compiling a string into bytecode.
  Useful for loading classes generated at runtime without using files.
- Added ByteCodeLoader.java for defining a new class when you already
  have the bytecode.

Testing:
- Added the new test TestMetaspacePerfCounters.java
- JPRT

Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659

Thanks,
Erik


From mikael.gerdin at oracle.com  Thu Aug 15 06:54:33 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 15 Aug 2013 15:54:33 +0200
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <20130814144906.GC2649@ehelin-thinkpad>
References: <20130814144906.GC2649@ehelin-thinkpad>
Message-ID: <520CDD99.70403@oracle.com>

Erik,

On 08/14/2013 04:49 PM, Erik Helin wrote:
> Hi all,
>
> this change adds performance counters for compressed class space.
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
>
> Changes to hotspot:
> The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
> where the class MetaspaceCounters has been split up into
> MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
> an instance of MetaspacePerfCounters. The class
> CompressedClassSpaceCounters has been added which also has its own
> instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
> updates the actual performance counters.

I'm a bit concerned about the exception handling in the perf variable 
creation. But it appears to be similar to the other places where perf 
variables are created.

Creating a 0-reporting perf counter if -UseCompressedKlassPointers seems 
consistent with the rest of the code.

I'd say this is fine, but as Coleen mentioned you should verify this 
with Harold's change for CDS+CompressedOops.

>
> The changes in metaspace.hpp/cpp were needed to get some additional data
> from the metaspace data structures. The method
> free_chunks_in_total(mdtype) was made public and the method
> free_bytes(mdtype) was added. Some common functionality was extracted
> into get_space_list(mdtype) which got rid of some duplicated code.
>
> The changes in:
> - g1MonitorinSupport.cpp
> - parallelScavengeHeap.cpp
> - genCollectedHeap.cpp
> - universe.cpp
> are only "one-liners" that either update or initialize the new performance
> counters.
>
> Changes to the testlibrary:
> - Added Asserts.java for writing asserts like "assertTrue",
>    "assertEquals", etc.
> - Added PerfCounter.java and PerfCounters.java to make it easy to
>    inspect performance counters for the currently running VM.
> - Added InputArguments.java so a test can check the arguments it got
>    passed.
> - Added InMemoryJavaCompiler.java for compiling a string into bytecode.
>    Useful for loading classes generated at runtime without using files.
> - Added ByteCodeLoader.java for defining a new class when you already
>    have the bytecode.

The test code looks fine.

/Mikael
>
> Testing:
> - Added the new test TestMetaspacePerfCounters.java
> - JPRT
>
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
>
> Thanks,
> Erik
>


From yumin.qi at oracle.com  Thu Aug 15 08:35:07 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 15 Aug 2013 08:35:07 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
Message-ID: <520CF52B.6050000@oracle.com>

Hi,

   Can I have your review for this small changes?
http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
<http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>

    This is for a enhancement to add head/tail message to the logging 
files to assist reading GC output.
    1. modified prompt message if invalid arguments used for log rotating;
    2. add time and file name message to log file head/tail.
    3. for easily identify which log file is current, use file name like 
<filename>.n.current, after it reaches maximum size, rename it to 
<filename>.n
         On Windows, there is no F_OK (existing test) definition, F_OK 
is defined as "0" and for _access of VC++, it just describes:

modevalue

	

Checks file for

00

	

Existence only

02

	

Write-only

04

	

Read-only

06

	

Read and write


http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
The definition are consistent with unistd.h.

     Test: JPRT and jtreg.

    Thanks
    Yumin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130815/949828ed/attachment-0001.html 

From david.r.chase at oracle.com  Thu Aug 15 09:05:49 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 15 Aug 2013 12:05:49 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately reports
	the result of a LinkResolver operation
Message-ID: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>

Webrev: http://cr.openjdk.java.net/~drchase/8014013/webrev.01/

Bug: The addition of interface (default) methods made the old way
of resolving method invocation not be right. 
In addition, the code was fiddly and distributed through the source.
See also duplicate 7086758,
"MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited"

Fix: Enhance method resolution (add "CallKind")
and the data structures for reporting resolution results,
and centralize the process as much as possible.

Testing:

Note: this fix is bug-for-bug-compatible with current on jdk/lambda/vm/DefaultMethodsTest.java 

64-bit Intel (MacOS):
jtreg - compiler
jtreg - jdk/{lib,sun,java/util, java/lang, jdk}
ute/tonga - vm.quick.testlist

32-bit Intel (Ubuntu)
Point checks on all the corner cases from the 64-bit testing.
(jck60008, b7087658)
jtreg - jdk/{java/util, java/lang, jdk}

Solaris-sparc
jtreg - jdk/{java/util, java/lang, jdk}

Also compiled on Windows/VS2010 w/ JPRT.



From erik.helin at oracle.com  Thu Aug 15 09:52:42 2013
From: erik.helin at oracle.com ('Erik Helin')
Date: Thu, 15 Aug 2013 18:52:42 +0200
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <011301ce99bc$38b747c0$aa25d740$@oracle.com>
References: <20130814144906.GC2649@ehelin-thinkpad>
	<011301ce99bc$38b747c0$aa25d740$@oracle.com>
Message-ID: <20130815165242.GA9178@ehelin-thinkpad>

On 2013-08-15, Christian Tornqvist wrote:
> Hi Erik,

Hi Christian,

thanks for reviewing the test code!

On 2013-08-15, Christian Tornqvist wrote:
> First of all, I've only reviewed the test part of this change. Please add a
> small test for the Asserts class, this would make it a lot easier to
> fix/change it in the future.

Great idea! I've added a test, AssertsTests.java, for the Asserts class
in the following webrev:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.03/

For the changes leading up to webrev.03, please see:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/
http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/
http://cr.openjdk.java.net/~ehelin/8014659/webrev.02-03/

On 2013-08-15, Christian Tornqvist wrote:
> Otherwise I think the change looks good, thanks
> for adding Asserts and the other classes to testlibrary collection :)

Thanks!
Erik

> Thanks,
> Christian
> 
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net
> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Erik
> Helin
> Sent: Wednesday, August 14, 2013 10:49 AM
> To: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
> space
> 
> Hi all,
> 
> this change adds performance counters for compressed class space.
> 
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
> 
> Changes to hotspot:
> The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
> where the class MetaspaceCounters has been split up into MetaspaceCounters
> and MetaspacePerfCounters. MetaspaceCounters now owns an instance of
> MetaspacePerfCounters. The class CompressedClassSpaceCounters has been added
> which also has its own instance of MetaspacePerfCounters.
> MetaspacePerfCounters initializes and updates the actual performance
> counters.
> 
> The changes in metaspace.hpp/cpp were needed to get some additional data
> from the metaspace data structures. The method
> free_chunks_in_total(mdtype) was made public and the method
> free_bytes(mdtype) was added. Some common functionality was extracted into
> get_space_list(mdtype) which got rid of some duplicated code.
> 
> The changes in:
> - g1MonitorinSupport.cpp
> - parallelScavengeHeap.cpp
> - genCollectedHeap.cpp
> - universe.cpp
> are only "one-liners" that either update or initialize the new performance
> counters.
> 
> Changes to the testlibrary:
> - Added Asserts.java for writing asserts like "assertTrue",
>   "assertEquals", etc.
> - Added PerfCounter.java and PerfCounters.java to make it easy to
>   inspect performance counters for the currently running VM.
> - Added InputArguments.java so a test can check the arguments it got
>   passed.
> - Added InMemoryJavaCompiler.java for compiling a string into bytecode.
>   Useful for loading classes generated at runtime without using files.
> - Added ByteCodeLoader.java for defining a new class when you already
>   have the bytecode.
> 
> Testing:
> - Added the new test TestMetaspacePerfCounters.java
> - JPRT
> 
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
> 
> Thanks,
> Erik
> 

From harold.seigel at oracle.com  Thu Aug 15 10:48:29 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 15 Aug 2013 13:48:29 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <520B7649.6080604@oracle.com>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
	<520B4228.7000307@oracle.com> <520B758C.2080405@oracle.com>
	<520B7649.6080604@oracle.com>
Message-ID: <520D146D.4070003@oracle.com>

Hi,

Please review this updated version of the fix for 8003424: 
http://cr.openjdk.java.net/~hseigel/bug_8003424.4/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.4/>

Other than removing an obsolete comment from universe.cpp, only the 
tests have been changed since the previous webrev.  A few test errors 
were fixed, '@run main' tags were added, and the handling of cases where 
CDS cannot be used has been improved.

Thanks, Harold

On 8/14/2013 8:21 AM, Mikael Gerdin wrote:
> Harold,
>
> On 2013-08-14 14:18, harold seigel wrote:
>> Hi Mikael,
>>
>> Thanks for the review.
>>
>> In test CDSCompressedKPtrs.java, RuntimeException gets thrown by
>> output.shouldContain(), if it does not find the specified text in the
>> test's output.  In this test, it may not find "sharing" in the test
>> output if the JVM was unable to compatibly allocate the class
>> metaspace.  If the class metaspace does not get allocated near the CDS
>> region then the JVM turns off CDS, disabling sharing.  Since this is a
>> valid execution path, it shouldn't cause the test to fail.
>>
>> I've added a comment and changed the test a bit to try and make it 
>> clearer:
>>
>>        } catch (RuntimeException e) {
>>          // Report 'passed' if CDS was turned off because we could not
>> allocate
>>          // the klass metaspace at an address that would work with CDS.
>>          output.shouldContain("Could not allocate metaspace at a
>> compatible address");
>>          output.shouldHaveExitValue(1);
>>        }
>
> I see. I suspected that this was the case but it wasn't clear earlier. 
> I think that the comment is sufficient to communicate this.
>
>
> /Mikael
>
>>
>> Thanks, Harold
>>
>> On 8/14/2013 4:39 AM, Mikael Gerdin wrote:
>>> Harold,
>>>
>>> On 2013-08-09 16:57, Harold Seigel wrote:
>>>> Hi,
>>>>
>>>> Please review this latest version of the bug fix for 8003424:
>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/
>>>>
>>>>
>>>> This new version includes the following changes:
>>>>
>>>> 1. macroAssembler_sparc.cpp
>>>>
>>>>     a. Merged two versions of reinit_heapbase() into one.
>>>>
>>>>     b. Improved decode_klass_not_null(src, dst) to not use G6 if
>>>> shift == 0.
>>>>
>>>>
>>>> 2. macroAssembler_x86.cpp
>>>>
>>>>     a. Merged two versions of reinit_heapbase() into one.
>>>>
>>>>     b. Improved encode_klass_not_null(src, dst) to not use R12.
>>>>
>>>>     c. Replaced leaq with addq in decode_klass_not_null(src, dst).
>>>>
>>>>
>>>> 3. Improved variable names in heap.cpp.
>>>>
>>>>
>>>> 4. metaspace.cpp
>>>>
>>>>     a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more
>>>> understandable.
>>>>
>>>>     b. Moved set_narrow_klass_base_and_shift() near
>>>> can_use_cds_with_metaspace_addr().
>>>>
>>>>     c. Changed unneeded conditional in initialize_class_space() 
>>>> into an
>>>> assert.
>>>>
>>>>
>>>> 5. arguments.cpp
>>>>
>>>>     a. Fixed problem with -Xshare:dump and disabled compression.
>>>>
>>>>     b. Moved UseCompressedKlassPointers code into new function:
>>>> set_use_compressed_klass_ptrs().
>>>>
>>>>     c. Fixed bug 8005933 that turned off CDS for -server even if
>>>> -Xshare:auto was explicitly specified.
>>>>
>>>>
>>>> 6. Increased default value of ClassMetaspaceSize to 1*G in 
>>>> globals.hpp.
>>>>
>>>>
>>>> 7. Fixed indentation issues in metaspace.cpp and other modules.
>>>
>>> The VM changes look good to me.
>>>
>>> I have a question about the test CDSCompressedKPtrs.java
>>>
>>> What RuntimeException do you expect and why is it ok that we can't use
>>> the shared archive if you get such an exception?
>>>
>>> I think at least a comment about why the test is supposed to pass even
>>> if we can't use the shared archive.
>>>
>>> /Mikael
>>>
>>>>
>>>>
>>>> Thanks, Harold
>>>>
>>>> ----- Original Message -----
>>>> From: harold.seigel at oracle.com
>>>> To: coleen.phillimore at oracle.com
>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>> Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern
>>>> Subject: Re: Request for review: 8003424 - Enable Class Data 
>>>> Sharing for
>>>> CompressedOops
>>>>
>>>> The purpose of this assert is to verify that the two methods in the 
>>>> 'if'
>>>> clause closed the map file and disabled UseSharedSpaces if they 
>>>> detected
>>>> a problem when trying to use CDS.
>>>>
>>>>        if (mapinfo->initialize() &&
>>>> MetaspaceShared::map_shared_spaces(mapinfo)) {
>>>>          FileMapInfo::set_current_info(mapinfo);
>>>>        } else {
>>>>          assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>>                 "archive file not closed or shared spaces not
>>>> disabled.");
>>>>        }
>>>>
>>>> ----- Original Message -----
>>>> From: harold.seigel at oracle.com
>>>> To: coleen.phillimore at oracle.com
>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>> Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
>>>> Subject: Re: Request for review: 8003424 - Enable Class Data 
>>>> Sharing for
>>>> CompressedOops
>>>>
>>>> This is a bug that Stefan Karlsson also discovered.  To fix it, I've
>>>> changed the code to this:
>>>>
>>>>    if (DumpSharedSpaces) {
>>>>      if (RequireSharedSpaces) {
>>>>        warning("cannot dump shared archive while using shared 
>>>> archive");
>>>>      }
>>>>      UseSharedSpaces = false;
>>>> #ifdef _LP64
>>>>      if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>        vm_exit_during_initialization(
>>>>          "Cannot dump shared archive when UseCompressedOops or
>>>> UseCompressedKlassPointers is off.", NULL);
>>>>      }
>>>>
>>>> Harold
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: coleen.phillimore at oracle.com
>>>> To: hotspot-runtime-dev at openjdk.java.net
>>>> Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
>>>> Subject: Re: Request for review: 8003424 - Enable Class Data 
>>>> Sharing for
>>>> CompressedOops
>>>>
>>>>
>>>> Yes, there should be a check for that too.  Now I'll really let Harold
>>>> answer.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
>>>>  > Coleen, Harold
>>>>  >
>>>>  > > The InstanceKlass has offsets to fields in the instance, and they
>>>>  > depend
>>>>  > > on both compressed oops and compressed klass pointers.   So both
>>>>  > have to
>>>>  > > be on for the offsets to be valid.
>>>>  >
>>>>  > So there is dependency on UseCompressedOops and
>>>>  > UseCompressedKlassPointers flags during dump.
>>>>  >
>>>>  > Then why the check is done only for UseSharedSpaces and not for
>>>>  > DumpSharedSpaces?:
>>>>  >
>>>>  >     if (DumpSharedSpaces) {
>>>>  >       if (RequireSharedSpaces) {
>>>>  >         warning("cannot dump shared archive while using shared
>>>> archive");
>>>>  >       }
>>>>  >       UseSharedSpaces = false;
>>>>  > + #ifdef _LP64
>>>>  > +   } else {
>>>>  > +     // UseCompressedOops and UseCompressedKlassPointers must 
>>>> be on
>>>>  > for UseSharedSpaces.
>>>>  > +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>  > +       no_shared_spaces();
>>>>  > +     }
>>>>  > + #endif
>>>>  >     }
>>>>  >
>>>>  > Thanks,
>>>>  > Vladimir
>>>>  >
>>>>  > On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>>>>  >>
>>>>  >> Hi Vladimir,
>>>>  >>
>>>>  >> I have a couple of answers and I'll let Harold answer the rest.
>>>>  >>
>>>>  >> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>>>>  >>> On 8/7/13 8:34 AM, harold seigel wrote:
>>>>  >>>> Hi Vladimir,
>>>>  >>>>
>>>>  >>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>>>  >>>>> Harold,
>>>>  >>>>>
>>>>  >>>>> Note, on SPARC set() could generate up to 8 instructions to 
>>>> load
>>>>  >>>>> 64-bit constant into register. So I am not sure that it will be
>>>>  >>>>> faster
>>>>  >>>>> than load.
>>>>  >>>> We thought it would be faster because it doesn't need to load
>>>> anything
>>>>  >>>> from memory.
>>>>  >>>
>>>>  >>> For good value (0x800000000) it should use only 2-3 instructions.
>>>>  >>> I think you can keep using set().
>>>>  >>>
>>>>  >>>>>
>>>>  >>>>> I can't find where in CDS you store information about 
>>>> compressed
>>>>  >>>>> klass
>>>>  >>>>> pointers and compressed oops parameters which were used during
>>>> dump?
>>>>  >>>>> How you verify that correct parameters/flags are ussed when
>>>> such CDS
>>>>  >>>>> is used later?
>>>>  >>>> No compressed klass pointers nor compressed oops get written to
>>>> the
>>>>  >>>> archive.  So, the compressed klass pointers and compressed oops
>>>>  >>>> parameters do not need to be recorded in the archive.
>>>>  >>>
>>>>  >>> So you are saying that all klass pointers (references to
>>>> klasses) in
>>>>  >>> metadata structures in metaspace are full.
>>>>  >>
>>>>  >> Yes, they are.  (methodOops weren't in the
>>>> InstanceKlass::_methods array
>>>>  >> with Permgen but they are uncompressed now).
>>>>  >>
>>>>  >>> And klass pointers are only compressed in java object headers
>>>> (which
>>>>  >>> are not part of CDS). Right?
>>>>  >>
>>>>  >> The InstanceKlass has offsets to fields in the instance, and they
>>>> depend
>>>>  >> on both compressed oops and compressed klass pointers.   So both
>>>> have to
>>>>  >> be on for the offsets to be valid.
>>>>  >>
>>>>  >> But the base and compressed values are not stored anywhere in the
>>>> CDS
>>>>  >> archive.
>>>>  >>
>>>>  >>> And you don't care about UseCompressedOops and
>>>>  >>> UseCompressedKlassPointers flags settings when you dump it into
>>>>  >>> archive. The only limit is:
>>>>  >>>
>>>>  >>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) -
>>>> cds_total
>>>>  >>>
>>>>  >>> Then I don't understand why you can't use/load CDS archive when
>>>> coop
>>>>  >>> or compklass are off:
>>>>  >>>
>>>>  >>> > If coop is turned off then CDS cannot be used.  CDS will 
>>>> only be
>>>>  >>> > supported if both UseCompressedOops and
>>>> UseCompressedKlassPointers
>>>>  >>> are
>>>>  >>> > TRUE.
>>>>  >>>
>>>>  >>> Also based on code in arguments.cpp it is allowed to specify
>>>>  >>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on
>>>> command line:
>>>>  >>>
>>>>  >>> 1466     // Turn on UseCompressedKlassPointers too
>>>>  >>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>>>>  >>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>>>>  >>> 1469     }
>>>>  >>>
>>>>  >>> Did you tested such combination?
>>>>  >>
>>>>  >> I should let Harold answer this but I believe this is what his 
>>>> test
>>>>  >> does.  For CDS on 64 bit, both must be on.   We didn't want to
>>>> create 4
>>>>  >> different archives.   And it wouldn't make too much sense since
>>>> CDS for
>>>>  >> 64 bit is a footprint savings so why would you use it without
>>>>  >> compressing oops and class pointers?  It's not a startup 
>>>> savings on
>>>>  >> server because we turn off interpreter bytecode quickening.
>>>>  >>
>>>>  >> Coleen
>>>>  >>
>>>>  >>>
>>>>  >>>>>
>>>>  >>>>> set_narrow_klass_base_and_shift() and
>>>>  >>>>> can_use_cds_with_metaspace_addr() have the same code for
>>>>  >>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>>>  >>>>> can_use_cds_with_metaspace_addr() from
>>>>  >>>>> set_narrow_klass_base_and_shift() ?
>>>>  >>>> I could add new inlined methods that determine the
>>>> higher_address and
>>>>  >>>> lower_base when UseSharedSpaces is true and have them called 
>>>> from
>>>>  >>>> set_narrow_klass_base_and_shift() and
>>>>  >>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>>>>  >>>
>>>>  >>> I tried several approaches but your implementation is more
>>>> clean. So I
>>>>  >>> agree to keep what you have now.
>>>>  >>>
>>>>  >>>
>>>>  >>> Also I found strange assert which should always fail (old code in
>>>>  >>> global_initialize() in metaspace.cpp):
>>>>  >>>
>>>>  >>> 2959     if (UseSharedSpaces) {
>>>>  >>> ...
>>>>  >>> 2969       } else {
>>>>  >>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>>  >>> 2971                "archive file not closed or shared spaces not
>>>>  >>> disabled.");
>>>>  >>>
>>>>  >>> Thanks,
>>>>  >>> Vladimir
>>>>  >>>
>>>>  >>>>>
>>>>  >>>>> I see that you unconditionally set comp klass ptr base and
>>>> shift for
>>>>  >>>>> DumpSharedSpaces. Should you do the check similar to
>>>>  >>>>> can_use_cds_with_metaspace_addr() to find if you can do 
>>>> that? You
>>>>  >>>>> don't even check UseCompressedKlassPointers.
>>>>  >>>> I don't think the checks are needed because the information
>>>> written to
>>>>  >>>> the archive is not affected by the size of the class metaspace.
>>>>  >>>>
>>>>  >>>> Also, I recently added code to arguments.cpp that will 
>>>> generate an
>>>>  >>>> error
>>>>  >>>> if UseCompressedOops or UseCompressedKlassPointers is turned
>>>> off and
>>>>  >>>> DumpSharedSpaces is on.
>>>>  >>>>>
>>>>  >>>>> Why you have next limitation? What if coop can't be used
>>>> because of
>>>>  >>>>> big heap?:
>>>>  >>>>>
>>>>  >>>>> +     // UseCompressedOops and UseCompressedKlassPointers must
>>>> be on
>>>>  >>>>> for UseSharedSpaces.
>>>>  >>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>  >>>>> +       no_shared_spaces();
>>>>  >>>> If coop is turned off then CDS cannot be used.  CDS will only be
>>>>  >>>> supported if both UseCompressedOops and
>>>> UseCompressedKlassPointers are
>>>>  >>>> TRUE.
>>>>  >>>>>
>>>>  >>>>> Could you move UseCompressedKlassPointers code in
>>>> arguments.cpp into
>>>>  >>>>> separate method similar to set_use_compressed_oops()?
>>>>  >>>> Done.
>>>>  >>>>>
>>>>  >>>>> About new tests.
>>>>  >>>>> The first test in CDSCompressedKPtrsError misses
>>>>  >>>>> -XX:+UseCompressedOops flag.
>>>>  >>>> Fixed.
>>>>  >>>>>
>>>>  >>>>> Could you also test cross flags combinations?:
>>>>  >>>>>
>>>>  >>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>>>  >>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>>>  >>>> Done.
>>>>  >>>>>
>>>>  >>>>> It would be nice to have test to check ClassMetaspaceSize value
>>>>  >>>>> range.
>>>>  >>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither
>>>> maxint
>>>>  >>>>> or maxuint.
>>>>  >>>> A member of our runtime SQE group is writing additional tests.
>>>> I'll
>>>>  >>>> ask
>>>>  >>>> him to write a ClassMetaspaceSize range test.
>>>>  >>>>
>>>>  >>>> We chose 3Gb because we thought it was a sufficiently large 
>>>> size.
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> About code style, indention. We align next line to
>>>> corresponding part
>>>>  >>>>> of previous line if we need to split a line. And sometimes 
>>>> it is
>>>>  >>>>> better to keep one long line. I understand some of them were
>>>> before
>>>>  >>>>> your changes but, please, clean up at lest ones you touched.
>>>>  >>>> Done.
>>>>  >>>>>
>>>>  >>>>> Cases in metaspace.cpp:
>>>>  >>>>>
>>>>  >>>>> 2263   assert(raw_word_size >= min_size,
>>>>  >>>>> 2264     err_msg("Should not deallocate dark matter "
>>>> SIZE_FORMAT "<"
>>>>  >>>>> SIZE_FORMAT, word_size, min_size));
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2485   if (Metaspace::using_class_space() &&
>>>>  >>>>> 2486 (Metaspace::class_space_list() != NULL)) {
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>>>  >>>>> 2575 (Metaspace::using_class_space() ?
>>>>  >>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 
>>>> 0) :
>>>>  >>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>>>  >>>>> SIZE_FORMAT ", "
>>>>  >>>>> 2695 SIZE_FORMAT " small(s) " SIZE_FORMAT
>>>>  >>>>> ", "
>>>>  >>>>> 2696 SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>>>  >>>>> ", "
>>>>  >>>>> 2697                            "large count " SIZE_FORMAT,
>>>>  >>>>> 2698 cls_specialized_count, cls_specialized_waste,
>>>>  >>>>> 2699              cls_small_count, cls_small_waste,
>>>>  >>>>> 2700              cls_medium_count, cls_medium_waste,
>>>>  >>>>> cls_humongous_count);
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G >
>>>>  >>>>> addr) &&
>>>>  >>>>> 2873 can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 2889 vm_exit_during_initialization(err_msg(
>>>>  >>>>> 2890           "Could not allocate metaspace: %d bytes",
>>>>  >>>>> 2891 class_metaspace_size()));
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 3107     return using_class_space() ?
>>>>  >>>>> 3108 class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 3157     if (is_class && using_class_space()) {
>>>>  >>>>> 3158 class_vsm()->deallocate(ptr, word_size);
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> 3305   return space_list()->contains(ptr) ||
>>>>  >>>>> 3306     (using_class_space() &&
>>>> class_space_list()->contains(ptr));
>>>>  >>>>>
>>>>  >>>>> metaspace.hpp:
>>>>  >>>>>
>>>>  >>>>>  270     return
>>>> _allocated_capacity_words[Metaspace::NonClassType] +
>>>>  >>>>>  271 (Metaspace::using_class_space() ?
>>>>  >>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>>  >>>>>
>>>>  >>>>>  285     return 
>>>> _allocated_used_words[Metaspace::NonClassType] +
>>>>  >>>>>  286 (Metaspace::using_class_space() ?
>>>>  >>>>>  287 _allocated_used_words[Metaspace::ClassType] : 0);
>>>>  >>>>>
>>>>  >>>>> universe.cpp:
>>>>  >>>>>
>>>>  >>>>>  849 assert((intptr_t)Universe::narrow_oop_base() <=
>>>>  >>>>> (intptr_t)(Universe::heap()->base() -
>>>>  >>>>>  850     os::vm_page_size()) ||
>>>>  >>>>>  851 Universe::narrow_oop_base() == NULL, "invalid
>>>>  >>>>> value");
>>>>  >>>>>
>>>>  >>>>>
>>>>  >>>>> Thanks,
>>>>  >>>>> Vladimir
>>>>  >>>>>
>>>>  >>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>>  >>>>>> Hi,
>>>>  >>>>>>
>>>>  >>>>>> Please review this updated webrev for bug 8003424:
>>>>  >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>>  >>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>  >>>>>>
>>>>  >>>>>> The updated webrev has a lot of changes from the previous
>>>> webrev,
>>>>  >>>>>> including the following:
>>>>  >>>>>>
>>>>  >>>>>>     1. Class metaspace information is now output when
>>>>  >>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>>  >>>>>>
>>>>  >>>>>>     2. decode_klass_not_null(Register dst, Register src) no
>>>> longer
>>>>  >>>>>>     clobbers R12.
>>>>  >>>>>>
>>>>  >>>>>>     3. Method using_class_vsm() was renamed to
>>>> using_class_space().
>>>>  >>>>>>
>>>>  >>>>>>     4. Type narrowKlass was added and replaces narrowOop, 
>>>> where
>>>>  >>>>>> appropriate.
>>>>  >>>>>>
>>>>  >>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>>>  >>>>>> unnecessary.
>>>>  >>>>>>
>>>>  >>>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>  >>>>>>
>>>>  >>>>>>     7. Method max_heap_for_compressed_oops(), in
>>>> arguments.cpp, was
>>>>  >>>>>> updated.
>>>>  >>>>>>
>>>>  >>>>>> Performance tests were run by Jenny using specjvm2008,
>>>> specjbb2005,
>>>>  >>>>>> and
>>>>  >>>>>> specjbb2013.  The results showed no significant performance
>>>>  >>>>>> difference
>>>>  >>>>>> in terms of scores and gc behavior.
>>>>  >>>>>>
>>>>  >>>>>> Additional testing was done on Solaris Sparc and Linux x86 
>>>> using
>>>>  >>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 
>>>> & 32.
>>>>  >>>>>>
>>>>  >>>>>> Please let me know what additional tests should be run.
>>>>  >>>>>>
>>>>  >>>>>> Thanks!
>>>>  >>>>>> Harold
>>>>  >>>>>>
>>>>  >>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>  >>>>>>> Hi Harold,
>>>>  >>>>>>>
>>>>  >>>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>  >>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) 
>>>> which
>>>>  >>>>>>> means
>>>>  >>>>>>> that
>>>>  >>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will
>>>> need R12,
>>>>  >>>>>>> unless
>>>>  >>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does
>>>> that
>>>>  >>>>>>> make
>>>>  >>>>>>> sense?
>>>>  >>>>>>>
>>>>  >>>>>>> My bad, I miscalculated. But we have "perfect value"
>>>> 0x800000000
>>>>  >>>>>>> and I
>>>>  >>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>>>  >>>>>>> (assuming or
>>>>  >>>>>>> with check that class metaspace size < 32Gb).
>>>>  >>>>>>>
>>>>  >>>>>>> > Is there one prefix byte per instruction, or just for 
>>>> certain
>>>>  >>>>>>> instructions?
>>>>  >>>>>>>
>>>>  >>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>>>  >>>>>>> prefix is
>>>>  >>>>>>> necessary only if an instruction references one of the 
>>>> extended
>>>>  >>>>>>> registers or uses a 64-bit operand."
>>>>  >>>>>>>
>>>>  >>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16
>>>> and
>>>>  >>>>>>> =32
>>>>  >>>>>>> and big java heap. Recently we got several bugs which 
>>>> indicated
>>>>  >>>>>>> that
>>>>  >>>>>>> we did not separate cleanly oops and klass pointers
>>>> en/decoding.
>>>>  >>>>>>>
>>>>  >>>>>>> Thanks,
>>>>  >>>>>>> Vladimir
>>>>  >>>>>>>
>>>>  >>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>  >>>>>>>> Hi Vladimir,
>>>>  >>>>>>>>
>>>>  >>>>>>>> Thank you for the review! Please see inline comments.
>>>>  >>>>>>>>
>>>>  >>>>>>>> Thanks, Harold
>>>>  >>>>>>>>
>>>>  >>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>  >>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>  >>>>>>>>>> Nice clean up, Harold
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> Could you add the size of class metaspace in output with
>>>>  >>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't 
>>>> want to
>>>>  >>>>>>>>>> remember an
>>>>  >>>>>>>>>> other very long flag name: 
>>>> TraceMetavirtualspaceAllocation.
>>>>  >>>>>>>> Will be done in next webrev.
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> Also it would be nice to print these info line (and
>>>> compressed
>>>>  >>>>>>>>>> oops
>>>>  >>>>>>>>>> info
>>>>  >>>>>>>>>> line) in hs_err files.
>>>>  >>>>>>>> I filed an enhancement bug for this: 8021264
>>>>  >>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL 
>>>> needed?" in
>>>>  >>>>>>>>>> x86_64.ad.
>>>>  >>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use
>>>>  >>>>>>>>>> arithmetic
>>>>  >>>>>>>>>> instructions which modify flags: subq, addq, shrq,
>>>> xorptr. Also
>>>>  >>>>>>>>>> note
>>>>  >>>>>>>>>> that code in .ad file does not check the encoding mode for
>>>>  >>>>>>>>>> narrow
>>>>  >>>>>>>>>> klass/oop so it should be conservative and assume that
>>>>  >>>>>>>>>> arithmetic
>>>>  >>>>>>>>>> instructions are used.
>>>>  >>>>>>>> OK. Thanks.
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass
>>>> base below
>>>>  >>>>>>>>>> 4Gb so
>>>>  >>>>>>>>>> the value is 32 bit. You can use it directly in narrow 
>>>> klass
>>>>  >>>>>>>>>> encoding/decoding without destroying R12.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> Correction. You can do it only if base < 2Gb max 
>>>> positive int
>>>>  >>>>>>>>> (sign
>>>>  >>>>>>>>> bit is extended so you will get wrong result with address
>>>> > 2gb).
>>>>  >>>>>>>> But the base will normally be 32Gb.  So this case won't 
>>>> happen
>>>>  >>>>>>>> very
>>>>  >>>>>>>> often.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> You definitely should not use R12 in
>>>>  >>>>>>>>> decode_klass_not_null(Register
>>>>  >>>>>>>>> dst, Register src) method where you have free 'dst' 
>>>> register.
>>>>  >>>>>>>> Will be fixed in next webrev.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G).
>>>> Actually it
>>>>  >>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it 
>>>> should be
>>>>  >>>>>>>>> 64Gb.
>>>>  >>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> decode:
>>>>  >>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>  >>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>  >>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>  >>>>>>>>>   }
>>>>  >>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>  >>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>  >>>>>>>>> }
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>  >>>>>>>>> (Universe::narrow_klass_base >> 
>>>> LogKlassAlignmentInBytes) <=
>>>>  >>>>>>>>> maxint
>>>>  >>>>>>>>> (max positive int).
>>>>  >>>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>  >>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment)
>>>> which means
>>>>  >>>>>>>> that
>>>>  >>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need
>>>> R12,
>>>>  >>>>>>>> unless
>>>>  >>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does 
>>>> that
>>>>  >>>>>>>> make
>>>>  >>>>>>>> sense?
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> And you have general memory reservation problem. At 
>>>> least on
>>>>  >>>>>>>>> Solaris,
>>>>  >>>>>>>>> as I remember, OS will always try to keep protected 4Kb 
>>>> pages
>>>>  >>>>>>>>> between
>>>>  >>>>>>>>> different requested memory regions. That is why in jdk7 we
>>>> first
>>>>  >>>>>>>>> reserve one huge space and then cut it on java heap, perm
>>>> gen and
>>>>  >>>>>>>>> protection page below heap to catch implicit NULL
>>>> exceptions with
>>>>  >>>>>>>>> compressed oops.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> So, please, verify that you are getting 'cds_address +
>>>> cds_total'
>>>>  >>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>>  >>>>>>>>> compressed
>>>>  >>>>>>>>> oops and with Xmx20Gb.
>>>>  >>>>>>>> I verifed that we get either cds_address+cds_total as the
>>>>  >>>>>>>> address, or
>>>>  >>>>>>>> CompressedKlassPointersBase as the address without CDS on
>>>> Linux,
>>>>  >>>>>>>> Windows
>>>>  >>>>>>>> 7, Mac OS, and Solaris 5.11. This is true with default heap
>>>>  >>>>>>>> sizes and
>>>>  >>>>>>>> -Xmx32G.
>>>>  >>>>>>>>
>>>>  >>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or
>>>> the
>>>>  >>>>>>>> desired
>>>>  >>>>>>>> CDS address for class metaspace regardless of heap size.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>>>  >>>>>>>>>> unfortunately we
>>>>  >>>>>>>>>> can't do other way. I assume you use max size because
>>>>  >>>>>>>>>> depending on
>>>>  >>>>>>>>>> registers used in instructions you will or will not get
>>>> prefix
>>>>  >>>>>>>>>> byte
>>>>  >>>>>>>>>> (r8-r15).
>>>>  >>>>>>>> Is there one prefix byte per instruction, or just for 
>>>> certain
>>>>  >>>>>>>> instructions?
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> I will look on changes in more details may be late.
>>>>  >>>>>>>>>
>>>>  >>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use
>>>>  >>>>>>>>> abbreviations
>>>>  >>>>>>>>> which are not obvious.
>>>>  >>>>>>>> I changed using_class_vsm() to using_class_space().
>>>>  >>>>>>>>>
>>>>  >>>>>>>>>
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> Thanks,
>>>>  >>>>>>>>>> Vladimir
>>>>  >>>>>>>>>>
>>>>  >>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>  >>>>>>>>>>> Hi,
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Please review this fix for bug 8003424.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Open webrev at
>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>  >>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>  >>>>>>>>>>> Open bug links at:
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> JBS Bug links at
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> This fix provides support for using compressed klass
>>>> pointers
>>>>  >>>>>>>>>>> with
>>>>  >>>>>>>>>>> CDS.
>>>>  >>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>>>  >>>>>>>>>>> platforms
>>>>  >>>>>>>>>>> when
>>>>  >>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of
>>>> allocating the
>>>>  >>>>>>>>>>> class
>>>>  >>>>>>>>>>> metaspace as part of the Java Heap allocation and 
>>>> locating
>>>>  >>>>>>>>>>> it at
>>>>  >>>>>>>>>>> the
>>>>  >>>>>>>>>>> base of that allocation, the metaspace will now be
>>>> allocated
>>>>  >>>>>>>>>>> separately,
>>>>  >>>>>>>>>>> above the Java heap.  This will enable future expansion
>>>> of the
>>>>  >>>>>>>>>>> metaspace
>>>>  >>>>>>>>>>> because it won't be backed up against the Java heap. If
>>>> CDS is
>>>>  >>>>>>>>>>> being
>>>>  >>>>>>>>>>> used, then the CDS region will be allocated between the
>>>> Java
>>>>  >>>>>>>>>>> heap and
>>>>  >>>>>>>>>>> the metaspace.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> The new class metaspace allocation code tries to allocate
>>>>  >>>>>>>>>>> memory at
>>>>  >>>>>>>>>>> 32G,
>>>>  >>>>>>>>>>> or above the CDS region, if it is present. Because of 
>>>> this,
>>>>  >>>>>>>>>>> encoding
>>>>  >>>>>>>>>>> and decoding of compressed klass pointers will always
>>>>  >>>>>>>>>>> require use
>>>>  >>>>>>>>>>> of a
>>>>  >>>>>>>>>>> base register. So, encoding and decoding of compressed
>>>> klass
>>>>  >>>>>>>>>>> pointers
>>>>  >>>>>>>>>>> will differ from compressed oops.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> There are no class metaspace allocation changes if
>>>>  >>>>>>>>>>> UseCompressedKlassPointers is turned off or if running 
>>>> on a
>>>>  >>>>>>>>>>> 32-bit
>>>>  >>>>>>>>>>> platform.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> The code changes also include some cleanup and will fix
>>>> bugs
>>>>  >>>>>>>>>>> 8016729,
>>>>  >>>>>>>>>>> 8011610, and 8003424.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Many of the modules in this webrev contain a lot of
>>>> changes.
>>>>  >>>>>>>>>>> Modules
>>>>  >>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>>>  >>>>>>>>>>> changed to
>>>>  >>>>>>>>>>> support the new encoding and decoding of compressed klass
>>>>  >>>>>>>>>>> pointers.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Module metaspace.cpp was changed significantly to support
>>>>  >>>>>>>>>>> the new
>>>>  >>>>>>>>>>> allocation for metaspace and the CDS region and to
>>>> determine
>>>>  >>>>>>>>>>> compressed
>>>>  >>>>>>>>>>> klass pointer encoding base and shifting values.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Most of the changes to module universe.cpp were to
>>>> remove code
>>>>  >>>>>>>>>>> related
>>>>  >>>>>>>>>>> to allocating metaspace and remove code that considered
>>>>  >>>>>>>>>>> compressed
>>>>  >>>>>>>>>>> klass
>>>>  >>>>>>>>>>> pointers when determining the compressed oops compression
>>>>  >>>>>>>>>>> mechanism.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were 
>>>> changed as
>>>>  >>>>>>>>>>> part
>>>>  >>>>>>>>>>> of a
>>>>  >>>>>>>>>>> cleanup requested by Coleen.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> These changes were tested with JCK Lang and VM tests, 
>>>> JTReg
>>>>  >>>>>>>>>>> tests,
>>>>  >>>>>>>>>>> JPRT,
>>>>  >>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and
>>>>  >>>>>>>>>>> vm.mlvm.testlist
>>>>  >>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and
>>>>  >>>>>>>>>>> -Xshare:off
>>>>  >>>>>>>>>>> (with
>>>>  >>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit
>>>>  >>>>>>>>>>> Linux and
>>>>  >>>>>>>>>>> 64-Bit
>>>>  >>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS.
>>>> JCK tests
>>>>  >>>>>>>>>>> were
>>>>  >>>>>>>>>>> run on Solaris x86.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> The performance impact of these changes is TBD.
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>> Thanks, Harold
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>>>>
>>>>  >>>>>>>>
>>>>  >>>>>>
>>>>  >>>>
>>>>  >>
>>>>
>>


From vladimir.kozlov at oracle.com  Thu Aug 15 11:28:18 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 Aug 2013 11:28:18 -0700
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <520D146D.4070003@oracle.com>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
	<520B4228.7000307@oracle.com> <520B758C.2080405@oracle.com>
	<520B7649.6080604@oracle.com> <520D146D.4070003@oracle.com>
Message-ID: <520D1DC2.4030604@oracle.com>

Good.

Thanks,
Vladimir

On 8/15/13 10:48 AM, harold seigel wrote:
> Hi,
>
> Please review this updated version of the fix for 8003424: http://cr.openjdk.java.net/~hseigel/bug_8003424.4/
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.4/>
>
> Other than removing an obsolete comment from universe.cpp, only the tests have been changed since the previous webrev.
> A few test errors were fixed, '@run main' tags were added, and the handling of cases where CDS cannot be used has been
> improved.
>
> Thanks, Harold
>
> On 8/14/2013 8:21 AM, Mikael Gerdin wrote:
>> Harold,
>>
>> On 2013-08-14 14:18, harold seigel wrote:
>>> Hi Mikael,
>>>
>>> Thanks for the review.
>>>
>>> In test CDSCompressedKPtrs.java, RuntimeException gets thrown by
>>> output.shouldContain(), if it does not find the specified text in the
>>> test's output.  In this test, it may not find "sharing" in the test
>>> output if the JVM was unable to compatibly allocate the class
>>> metaspace.  If the class metaspace does not get allocated near the CDS
>>> region then the JVM turns off CDS, disabling sharing.  Since this is a
>>> valid execution path, it shouldn't cause the test to fail.
>>>
>>> I've added a comment and changed the test a bit to try and make it clearer:
>>>
>>>        } catch (RuntimeException e) {
>>>          // Report 'passed' if CDS was turned off because we could not
>>> allocate
>>>          // the klass metaspace at an address that would work with CDS.
>>>          output.shouldContain("Could not allocate metaspace at a
>>> compatible address");
>>>          output.shouldHaveExitValue(1);
>>>        }
>>
>> I see. I suspected that this was the case but it wasn't clear earlier. I think that the comment is sufficient to
>> communicate this.
>>
>>
>> /Mikael
>>
>>>
>>> Thanks, Harold
>>>
>>> On 8/14/2013 4:39 AM, Mikael Gerdin wrote:
>>>> Harold,
>>>>
>>>> On 2013-08-09 16:57, Harold Seigel wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this latest version of the bug fix for 8003424:
>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/
>>>>>
>>>>>
>>>>> This new version includes the following changes:
>>>>>
>>>>> 1. macroAssembler_sparc.cpp
>>>>>
>>>>>     a. Merged two versions of reinit_heapbase() into one.
>>>>>
>>>>>     b. Improved decode_klass_not_null(src, dst) to not use G6 if
>>>>> shift == 0.
>>>>>
>>>>>
>>>>> 2. macroAssembler_x86.cpp
>>>>>
>>>>>     a. Merged two versions of reinit_heapbase() into one.
>>>>>
>>>>>     b. Improved encode_klass_not_null(src, dst) to not use R12.
>>>>>
>>>>>     c. Replaced leaq with addq in decode_klass_not_null(src, dst).
>>>>>
>>>>>
>>>>> 3. Improved variable names in heap.cpp.
>>>>>
>>>>>
>>>>> 4. metaspace.cpp
>>>>>
>>>>>     a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more
>>>>> understandable.
>>>>>
>>>>>     b. Moved set_narrow_klass_base_and_shift() near
>>>>> can_use_cds_with_metaspace_addr().
>>>>>
>>>>>     c. Changed unneeded conditional in initialize_class_space() into an
>>>>> assert.
>>>>>
>>>>>
>>>>> 5. arguments.cpp
>>>>>
>>>>>     a. Fixed problem with -Xshare:dump and disabled compression.
>>>>>
>>>>>     b. Moved UseCompressedKlassPointers code into new function:
>>>>> set_use_compressed_klass_ptrs().
>>>>>
>>>>>     c. Fixed bug 8005933 that turned off CDS for -server even if
>>>>> -Xshare:auto was explicitly specified.
>>>>>
>>>>>
>>>>> 6. Increased default value of ClassMetaspaceSize to 1*G in globals.hpp.
>>>>>
>>>>>
>>>>> 7. Fixed indentation issues in metaspace.cpp and other modules.
>>>>
>>>> The VM changes look good to me.
>>>>
>>>> I have a question about the test CDSCompressedKPtrs.java
>>>>
>>>> What RuntimeException do you expect and why is it ok that we can't use
>>>> the shared archive if you get such an exception?
>>>>
>>>> I think at least a comment about why the test is supposed to pass even
>>>> if we can't use the shared archive.
>>>>
>>>> /Mikael
>>>>
>>>>>
>>>>>
>>>>> Thanks, Harold
>>>>>
>>>>> ----- Original Message -----
>>>>> From: harold.seigel at oracle.com
>>>>> To: coleen.phillimore at oracle.com
>>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>>> Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern
>>>>> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
>>>>> CompressedOops
>>>>>
>>>>> The purpose of this assert is to verify that the two methods in the 'if'
>>>>> clause closed the map file and disabled UseSharedSpaces if they detected
>>>>> a problem when trying to use CDS.
>>>>>
>>>>>        if (mapinfo->initialize() &&
>>>>> MetaspaceShared::map_shared_spaces(mapinfo)) {
>>>>>          FileMapInfo::set_current_info(mapinfo);
>>>>>        } else {
>>>>>          assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>>>                 "archive file not closed or shared spaces not
>>>>> disabled.");
>>>>>        }
>>>>>
>>>>> ----- Original Message -----
>>>>> From: harold.seigel at oracle.com
>>>>> To: coleen.phillimore at oracle.com
>>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>>> Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
>>>>> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
>>>>> CompressedOops
>>>>>
>>>>> This is a bug that Stefan Karlsson also discovered.  To fix it, I've
>>>>> changed the code to this:
>>>>>
>>>>>    if (DumpSharedSpaces) {
>>>>>      if (RequireSharedSpaces) {
>>>>>        warning("cannot dump shared archive while using shared archive");
>>>>>      }
>>>>>      UseSharedSpaces = false;
>>>>> #ifdef _LP64
>>>>>      if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>>        vm_exit_during_initialization(
>>>>>          "Cannot dump shared archive when UseCompressedOops or
>>>>> UseCompressedKlassPointers is off.", NULL);
>>>>>      }
>>>>>
>>>>> Harold
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: coleen.phillimore at oracle.com
>>>>> To: hotspot-runtime-dev at openjdk.java.net
>>>>> Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada Eastern
>>>>> Subject: Re: Request for review: 8003424 - Enable Class Data Sharing for
>>>>> CompressedOops
>>>>>
>>>>>
>>>>> Yes, there should be a check for that too.  Now I'll really let Harold
>>>>> answer.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
>>>>>  > Coleen, Harold
>>>>>  >
>>>>>  > > The InstanceKlass has offsets to fields in the instance, and they
>>>>>  > depend
>>>>>  > > on both compressed oops and compressed klass pointers.   So both
>>>>>  > have to
>>>>>  > > be on for the offsets to be valid.
>>>>>  >
>>>>>  > So there is dependency on UseCompressedOops and
>>>>>  > UseCompressedKlassPointers flags during dump.
>>>>>  >
>>>>>  > Then why the check is done only for UseSharedSpaces and not for
>>>>>  > DumpSharedSpaces?:
>>>>>  >
>>>>>  >     if (DumpSharedSpaces) {
>>>>>  >       if (RequireSharedSpaces) {
>>>>>  >         warning("cannot dump shared archive while using shared
>>>>> archive");
>>>>>  >       }
>>>>>  >       UseSharedSpaces = false;
>>>>>  > + #ifdef _LP64
>>>>>  > +   } else {
>>>>>  > +     // UseCompressedOops and UseCompressedKlassPointers must be on
>>>>>  > for UseSharedSpaces.
>>>>>  > +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>>  > +       no_shared_spaces();
>>>>>  > +     }
>>>>>  > + #endif
>>>>>  >     }
>>>>>  >
>>>>>  > Thanks,
>>>>>  > Vladimir
>>>>>  >
>>>>>  > On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>>>>>  >>
>>>>>  >> Hi Vladimir,
>>>>>  >>
>>>>>  >> I have a couple of answers and I'll let Harold answer the rest.
>>>>>  >>
>>>>>  >> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>>>>>  >>> On 8/7/13 8:34 AM, harold seigel wrote:
>>>>>  >>>> Hi Vladimir,
>>>>>  >>>>
>>>>>  >>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>>>>  >>>>> Harold,
>>>>>  >>>>>
>>>>>  >>>>> Note, on SPARC set() could generate up to 8 instructions to load
>>>>>  >>>>> 64-bit constant into register. So I am not sure that it will be
>>>>>  >>>>> faster
>>>>>  >>>>> than load.
>>>>>  >>>> We thought it would be faster because it doesn't need to load
>>>>> anything
>>>>>  >>>> from memory.
>>>>>  >>>
>>>>>  >>> For good value (0x800000000) it should use only 2-3 instructions.
>>>>>  >>> I think you can keep using set().
>>>>>  >>>
>>>>>  >>>>>
>>>>>  >>>>> I can't find where in CDS you store information about compressed
>>>>>  >>>>> klass
>>>>>  >>>>> pointers and compressed oops parameters which were used during
>>>>> dump?
>>>>>  >>>>> How you verify that correct parameters/flags are ussed when
>>>>> such CDS
>>>>>  >>>>> is used later?
>>>>>  >>>> No compressed klass pointers nor compressed oops get written to
>>>>> the
>>>>>  >>>> archive.  So, the compressed klass pointers and compressed oops
>>>>>  >>>> parameters do not need to be recorded in the archive.
>>>>>  >>>
>>>>>  >>> So you are saying that all klass pointers (references to
>>>>> klasses) in
>>>>>  >>> metadata structures in metaspace are full.
>>>>>  >>
>>>>>  >> Yes, they are.  (methodOops weren't in the
>>>>> InstanceKlass::_methods array
>>>>>  >> with Permgen but they are uncompressed now).
>>>>>  >>
>>>>>  >>> And klass pointers are only compressed in java object headers
>>>>> (which
>>>>>  >>> are not part of CDS). Right?
>>>>>  >>
>>>>>  >> The InstanceKlass has offsets to fields in the instance, and they
>>>>> depend
>>>>>  >> on both compressed oops and compressed klass pointers.   So both
>>>>> have to
>>>>>  >> be on for the offsets to be valid.
>>>>>  >>
>>>>>  >> But the base and compressed values are not stored anywhere in the
>>>>> CDS
>>>>>  >> archive.
>>>>>  >>
>>>>>  >>> And you don't care about UseCompressedOops and
>>>>>  >>> UseCompressedKlassPointers flags settings when you dump it into
>>>>>  >>> archive. The only limit is:
>>>>>  >>>
>>>>>  >>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) -
>>>>> cds_total
>>>>>  >>>
>>>>>  >>> Then I don't understand why you can't use/load CDS archive when
>>>>> coop
>>>>>  >>> or compklass are off:
>>>>>  >>>
>>>>>  >>> > If coop is turned off then CDS cannot be used.  CDS will only be
>>>>>  >>> > supported if both UseCompressedOops and
>>>>> UseCompressedKlassPointers
>>>>>  >>> are
>>>>>  >>> > TRUE.
>>>>>  >>>
>>>>>  >>> Also based on code in arguments.cpp it is allowed to specify
>>>>>  >>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on
>>>>> command line:
>>>>>  >>>
>>>>>  >>> 1466     // Turn on UseCompressedKlassPointers too
>>>>>  >>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>>>>>  >>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, true);
>>>>>  >>> 1469     }
>>>>>  >>>
>>>>>  >>> Did you tested such combination?
>>>>>  >>
>>>>>  >> I should let Harold answer this but I believe this is what his test
>>>>>  >> does.  For CDS on 64 bit, both must be on.   We didn't want to
>>>>> create 4
>>>>>  >> different archives.   And it wouldn't make too much sense since
>>>>> CDS for
>>>>>  >> 64 bit is a footprint savings so why would you use it without
>>>>>  >> compressing oops and class pointers?  It's not a startup savings on
>>>>>  >> server because we turn off interpreter bytecode quickening.
>>>>>  >>
>>>>>  >> Coleen
>>>>>  >>
>>>>>  >>>
>>>>>  >>>>>
>>>>>  >>>>> set_narrow_klass_base_and_shift() and
>>>>>  >>>>> can_use_cds_with_metaspace_addr() have the same code for
>>>>>  >>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>>>>  >>>>> can_use_cds_with_metaspace_addr() from
>>>>>  >>>>> set_narrow_klass_base_and_shift() ?
>>>>>  >>>> I could add new inlined methods that determine the
>>>>> higher_address and
>>>>>  >>>> lower_base when UseSharedSpaces is true and have them called from
>>>>>  >>>> set_narrow_klass_base_and_shift() and
>>>>>  >>>> can_use_cds_with_metaspace_addr().  Would that be worth doing?
>>>>>  >>>
>>>>>  >>> I tried several approaches but your implementation is more
>>>>> clean. So I
>>>>>  >>> agree to keep what you have now.
>>>>>  >>>
>>>>>  >>>
>>>>>  >>> Also I found strange assert which should always fail (old code in
>>>>>  >>> global_initialize() in metaspace.cpp):
>>>>>  >>>
>>>>>  >>> 2959     if (UseSharedSpaces) {
>>>>>  >>> ...
>>>>>  >>> 2969       } else {
>>>>>  >>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>>>  >>> 2971                "archive file not closed or shared spaces not
>>>>>  >>> disabled.");
>>>>>  >>>
>>>>>  >>> Thanks,
>>>>>  >>> Vladimir
>>>>>  >>>
>>>>>  >>>>>
>>>>>  >>>>> I see that you unconditionally set comp klass ptr base and
>>>>> shift for
>>>>>  >>>>> DumpSharedSpaces. Should you do the check similar to
>>>>>  >>>>> can_use_cds_with_metaspace_addr() to find if you can do that? You
>>>>>  >>>>> don't even check UseCompressedKlassPointers.
>>>>>  >>>> I don't think the checks are needed because the information
>>>>> written to
>>>>>  >>>> the archive is not affected by the size of the class metaspace.
>>>>>  >>>>
>>>>>  >>>> Also, I recently added code to arguments.cpp that will generate an
>>>>>  >>>> error
>>>>>  >>>> if UseCompressedOops or UseCompressedKlassPointers is turned
>>>>> off and
>>>>>  >>>> DumpSharedSpaces is on.
>>>>>  >>>>>
>>>>>  >>>>> Why you have next limitation? What if coop can't be used
>>>>> because of
>>>>>  >>>>> big heap?:
>>>>>  >>>>>
>>>>>  >>>>> +     // UseCompressedOops and UseCompressedKlassPointers must
>>>>> be on
>>>>>  >>>>> for UseSharedSpaces.
>>>>>  >>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>>  >>>>> +       no_shared_spaces();
>>>>>  >>>> If coop is turned off then CDS cannot be used.  CDS will only be
>>>>>  >>>> supported if both UseCompressedOops and
>>>>> UseCompressedKlassPointers are
>>>>>  >>>> TRUE.
>>>>>  >>>>>
>>>>>  >>>>> Could you move UseCompressedKlassPointers code in
>>>>> arguments.cpp into
>>>>>  >>>>> separate method similar to set_use_compressed_oops()?
>>>>>  >>>> Done.
>>>>>  >>>>>
>>>>>  >>>>> About new tests.
>>>>>  >>>>> The first test in CDSCompressedKPtrsError misses
>>>>>  >>>>> -XX:+UseCompressedOops flag.
>>>>>  >>>> Fixed.
>>>>>  >>>>>
>>>>>  >>>>> Could you also test cross flags combinations?:
>>>>>  >>>>>
>>>>>  >>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>>>>  >>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>>>>  >>>> Done.
>>>>>  >>>>>
>>>>>  >>>>> It would be nice to have test to check ClassMetaspaceSize value
>>>>>  >>>>> range.
>>>>>  >>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither
>>>>> maxint
>>>>>  >>>>> or maxuint.
>>>>>  >>>> A member of our runtime SQE group is writing additional tests.
>>>>> I'll
>>>>>  >>>> ask
>>>>>  >>>> him to write a ClassMetaspaceSize range test.
>>>>>  >>>>
>>>>>  >>>> We chose 3Gb because we thought it was a sufficiently large size.
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> About code style, indention. We align next line to
>>>>> corresponding part
>>>>>  >>>>> of previous line if we need to split a line. And sometimes it is
>>>>>  >>>>> better to keep one long line. I understand some of them were
>>>>> before
>>>>>  >>>>> your changes but, please, clean up at lest ones you touched.
>>>>>  >>>> Done.
>>>>>  >>>>>
>>>>>  >>>>> Cases in metaspace.cpp:
>>>>>  >>>>>
>>>>>  >>>>> 2263   assert(raw_word_size >= min_size,
>>>>>  >>>>> 2264     err_msg("Should not deallocate dark matter "
>>>>> SIZE_FORMAT "<"
>>>>>  >>>>> SIZE_FORMAT, word_size, min_size));
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2485   if (Metaspace::using_class_space() &&
>>>>>  >>>>> 2486 (Metaspace::class_space_list() != NULL)) {
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>>>>  >>>>> 2575 (Metaspace::using_class_space() ?
>>>>>  >>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 0) :
>>>>>  >>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>>>>  >>>>> SIZE_FORMAT ", "
>>>>>  >>>>> 2695 SIZE_FORMAT " small(s) " SIZE_FORMAT
>>>>>  >>>>> ", "
>>>>>  >>>>> 2696 SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>>>>  >>>>> ", "
>>>>>  >>>>> 2697                            "large count " SIZE_FORMAT,
>>>>>  >>>>> 2698 cls_specialized_count, cls_specialized_waste,
>>>>>  >>>>> 2699              cls_small_count, cls_small_waste,
>>>>>  >>>>> 2700              cls_medium_count, cls_medium_waste,
>>>>>  >>>>> cls_humongous_count);
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G >
>>>>>  >>>>> addr) &&
>>>>>  >>>>> 2873 can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2889 vm_exit_during_initialization(err_msg(
>>>>>  >>>>> 2890           "Could not allocate metaspace: %d bytes",
>>>>>  >>>>> 2891 class_metaspace_size()));
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 3107     return using_class_space() ?
>>>>>  >>>>> 3108 class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 3157     if (is_class && using_class_space()) {
>>>>>  >>>>> 3158 class_vsm()->deallocate(ptr, word_size);
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 3305   return space_list()->contains(ptr) ||
>>>>>  >>>>> 3306     (using_class_space() &&
>>>>> class_space_list()->contains(ptr));
>>>>>  >>>>>
>>>>>  >>>>> metaspace.hpp:
>>>>>  >>>>>
>>>>>  >>>>>  270     return
>>>>> _allocated_capacity_words[Metaspace::NonClassType] +
>>>>>  >>>>>  271 (Metaspace::using_class_space() ?
>>>>>  >>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>>>  >>>>>
>>>>>  >>>>>  285     return _allocated_used_words[Metaspace::NonClassType] +
>>>>>  >>>>>  286 (Metaspace::using_class_space() ?
>>>>>  >>>>>  287 _allocated_used_words[Metaspace::ClassType] : 0);
>>>>>  >>>>>
>>>>>  >>>>> universe.cpp:
>>>>>  >>>>>
>>>>>  >>>>>  849 assert((intptr_t)Universe::narrow_oop_base() <=
>>>>>  >>>>> (intptr_t)(Universe::heap()->base() -
>>>>>  >>>>>  850     os::vm_page_size()) ||
>>>>>  >>>>>  851 Universe::narrow_oop_base() == NULL, "invalid
>>>>>  >>>>> value");
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> Thanks,
>>>>>  >>>>> Vladimir
>>>>>  >>>>>
>>>>>  >>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>>>  >>>>>> Hi,
>>>>>  >>>>>>
>>>>>  >>>>>> Please review this updated webrev for bug 8003424:
>>>>>  >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>>>  >>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>>  >>>>>>
>>>>>  >>>>>> The updated webrev has a lot of changes from the previous
>>>>> webrev,
>>>>>  >>>>>> including the following:
>>>>>  >>>>>>
>>>>>  >>>>>>     1. Class metaspace information is now output when
>>>>>  >>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>>>  >>>>>>
>>>>>  >>>>>>     2. decode_klass_not_null(Register dst, Register src) no
>>>>> longer
>>>>>  >>>>>>     clobbers R12.
>>>>>  >>>>>>
>>>>>  >>>>>>     3. Method using_class_vsm() was renamed to
>>>>> using_class_space().
>>>>>  >>>>>>
>>>>>  >>>>>>     4. Type narrowKlass was added and replaces narrowOop, where
>>>>>  >>>>>> appropriate.
>>>>>  >>>>>>
>>>>>  >>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>>>>  >>>>>> unnecessary.
>>>>>  >>>>>>
>>>>>  >>>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>>  >>>>>>
>>>>>  >>>>>>     7. Method max_heap_for_compressed_oops(), in
>>>>> arguments.cpp, was
>>>>>  >>>>>> updated.
>>>>>  >>>>>>
>>>>>  >>>>>> Performance tests were run by Jenny using specjvm2008,
>>>>> specjbb2005,
>>>>>  >>>>>> and
>>>>>  >>>>>> specjbb2013.  The results showed no significant performance
>>>>>  >>>>>> difference
>>>>>  >>>>>> in terms of scores and gc behavior.
>>>>>  >>>>>>
>>>>>  >>>>>> Additional testing was done on Solaris Sparc and Linux x86 using
>>>>>  >>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 & 32.
>>>>>  >>>>>>
>>>>>  >>>>>> Please let me know what additional tests should be run.
>>>>>  >>>>>>
>>>>>  >>>>>> Thanks!
>>>>>  >>>>>> Harold
>>>>>  >>>>>>
>>>>>  >>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>>  >>>>>>> Hi Harold,
>>>>>  >>>>>>>
>>>>>  >>>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>>  >>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) which
>>>>>  >>>>>>> means
>>>>>  >>>>>>> that
>>>>>  >>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will
>>>>> need R12,
>>>>>  >>>>>>> unless
>>>>>  >>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does
>>>>> that
>>>>>  >>>>>>> make
>>>>>  >>>>>>> sense?
>>>>>  >>>>>>>
>>>>>  >>>>>>> My bad, I miscalculated. But we have "perfect value"
>>>>> 0x800000000
>>>>>  >>>>>>> and I
>>>>>  >>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>>>>  >>>>>>> (assuming or
>>>>>  >>>>>>> with check that class metaspace size < 32Gb).
>>>>>  >>>>>>>
>>>>>  >>>>>>> > Is there one prefix byte per instruction, or just for certain
>>>>>  >>>>>>> instructions?
>>>>>  >>>>>>>
>>>>>  >>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>>>>  >>>>>>> prefix is
>>>>>  >>>>>>> necessary only if an instruction references one of the extended
>>>>>  >>>>>>> registers or uses a 64-bit operand."
>>>>>  >>>>>>>
>>>>>  >>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16
>>>>> and
>>>>>  >>>>>>> =32
>>>>>  >>>>>>> and big java heap. Recently we got several bugs which indicated
>>>>>  >>>>>>> that
>>>>>  >>>>>>> we did not separate cleanly oops and klass pointers
>>>>> en/decoding.
>>>>>  >>>>>>>
>>>>>  >>>>>>> Thanks,
>>>>>  >>>>>>> Vladimir
>>>>>  >>>>>>>
>>>>>  >>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>>  >>>>>>>> Hi Vladimir,
>>>>>  >>>>>>>>
>>>>>  >>>>>>>> Thank you for the review! Please see inline comments.
>>>>>  >>>>>>>>
>>>>>  >>>>>>>> Thanks, Harold
>>>>>  >>>>>>>>
>>>>>  >>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>  >>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>  >>>>>>>>>> Nice clean up, Harold
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> Could you add the size of class metaspace in output with
>>>>>  >>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't want to
>>>>>  >>>>>>>>>> remember an
>>>>>  >>>>>>>>>> other very long flag name: TraceMetavirtualspaceAllocation.
>>>>>  >>>>>>>> Will be done in next webrev.
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> Also it would be nice to print these info line (and
>>>>> compressed
>>>>>  >>>>>>>>>> oops
>>>>>  >>>>>>>>>> info
>>>>>  >>>>>>>>>> line) in hs_err files.
>>>>>  >>>>>>>> I filed an enhancement bug for this: 8021264
>>>>>  >>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL needed?" in
>>>>>  >>>>>>>>>> x86_64.ad.
>>>>>  >>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use
>>>>>  >>>>>>>>>> arithmetic
>>>>>  >>>>>>>>>> instructions which modify flags: subq, addq, shrq,
>>>>> xorptr. Also
>>>>>  >>>>>>>>>> note
>>>>>  >>>>>>>>>> that code in .ad file does not check the encoding mode for
>>>>>  >>>>>>>>>> narrow
>>>>>  >>>>>>>>>> klass/oop so it should be conservative and assume that
>>>>>  >>>>>>>>>> arithmetic
>>>>>  >>>>>>>>>> instructions are used.
>>>>>  >>>>>>>> OK. Thanks.
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass
>>>>> base below
>>>>>  >>>>>>>>>> 4Gb so
>>>>>  >>>>>>>>>> the value is 32 bit. You can use it directly in narrow klass
>>>>>  >>>>>>>>>> encoding/decoding without destroying R12.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> Correction. You can do it only if base < 2Gb max positive int
>>>>>  >>>>>>>>> (sign
>>>>>  >>>>>>>>> bit is extended so you will get wrong result with address
>>>>> > 2gb).
>>>>>  >>>>>>>> But the base will normally be 32Gb.  So this case won't happen
>>>>>  >>>>>>>> very
>>>>>  >>>>>>>> often.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> You definitely should not use R12 in
>>>>>  >>>>>>>>> decode_klass_not_null(Register
>>>>>  >>>>>>>>> dst, Register src) method where you have free 'dst' register.
>>>>>  >>>>>>>> Will be fixed in next webrev.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G).
>>>>> Actually it
>>>>>  >>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it should be
>>>>>  >>>>>>>>> 64Gb.
>>>>>  >>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> decode:
>>>>>  >>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>  >>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>  >>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>  >>>>>>>>>   }
>>>>>  >>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>  >>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>  >>>>>>>>> }
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>  >>>>>>>>> (Universe::narrow_klass_base >> LogKlassAlignmentInBytes) <=
>>>>>  >>>>>>>>> maxint
>>>>>  >>>>>>>>> (max positive int).
>>>>>  >>>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>>  >>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment)
>>>>> which means
>>>>>  >>>>>>>> that
>>>>>  >>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need
>>>>> R12,
>>>>>  >>>>>>>> unless
>>>>>  >>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). Does that
>>>>>  >>>>>>>> make
>>>>>  >>>>>>>> sense?
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> And you have general memory reservation problem. At least on
>>>>>  >>>>>>>>> Solaris,
>>>>>  >>>>>>>>> as I remember, OS will always try to keep protected 4Kb pages
>>>>>  >>>>>>>>> between
>>>>>  >>>>>>>>> different requested memory regions. That is why in jdk7 we
>>>>> first
>>>>>  >>>>>>>>> reserve one huge space and then cut it on java heap, perm
>>>>> gen and
>>>>>  >>>>>>>>> protection page below heap to catch implicit NULL
>>>>> exceptions with
>>>>>  >>>>>>>>> compressed oops.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> So, please, verify that you are getting 'cds_address +
>>>>> cds_total'
>>>>>  >>>>>>>>> address or CompressedKlassPointersBase without CDS and with
>>>>>  >>>>>>>>> compressed
>>>>>  >>>>>>>>> oops and with Xmx20Gb.
>>>>>  >>>>>>>> I verifed that we get either cds_address+cds_total as the
>>>>>  >>>>>>>> address, or
>>>>>  >>>>>>>> CompressedKlassPointersBase as the address without CDS on
>>>>> Linux,
>>>>>  >>>>>>>> Windows
>>>>>  >>>>>>>> 7, Mac OS, and Solaris 5.11. This is true with default heap
>>>>>  >>>>>>>> sizes and
>>>>>  >>>>>>>> -Xmx32G.
>>>>>  >>>>>>>>
>>>>>  >>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or
>>>>> the
>>>>>  >>>>>>>> desired
>>>>>  >>>>>>>> CDS address for class metaspace regardless of heap size.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>>>>  >>>>>>>>>> unfortunately we
>>>>>  >>>>>>>>>> can't do other way. I assume you use max size because
>>>>>  >>>>>>>>>> depending on
>>>>>  >>>>>>>>>> registers used in instructions you will or will not get
>>>>> prefix
>>>>>  >>>>>>>>>> byte
>>>>>  >>>>>>>>>> (r8-r15).
>>>>>  >>>>>>>> Is there one prefix byte per instruction, or just for certain
>>>>>  >>>>>>>> instructions?
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> I will look on changes in more details may be late.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use
>>>>>  >>>>>>>>> abbreviations
>>>>>  >>>>>>>>> which are not obvious.
>>>>>  >>>>>>>> I changed using_class_vsm() to using_class_space().
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> Thanks,
>>>>>  >>>>>>>>>> Vladimir
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>  >>>>>>>>>>> Hi,
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Please review this fix for bug 8003424.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Open webrev at
>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>  >>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>  >>>>>>>>>>> Open bug links at:
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> JBS Bug links at
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> This fix provides support for using compressed klass
>>>>> pointers
>>>>>  >>>>>>>>>>> with
>>>>>  >>>>>>>>>>> CDS.
>>>>>  >>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>>>>  >>>>>>>>>>> platforms
>>>>>  >>>>>>>>>>> when
>>>>>  >>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of
>>>>> allocating the
>>>>>  >>>>>>>>>>> class
>>>>>  >>>>>>>>>>> metaspace as part of the Java Heap allocation and locating
>>>>>  >>>>>>>>>>> it at
>>>>>  >>>>>>>>>>> the
>>>>>  >>>>>>>>>>> base of that allocation, the metaspace will now be
>>>>> allocated
>>>>>  >>>>>>>>>>> separately,
>>>>>  >>>>>>>>>>> above the Java heap.  This will enable future expansion
>>>>> of the
>>>>>  >>>>>>>>>>> metaspace
>>>>>  >>>>>>>>>>> because it won't be backed up against the Java heap. If
>>>>> CDS is
>>>>>  >>>>>>>>>>> being
>>>>>  >>>>>>>>>>> used, then the CDS region will be allocated between the
>>>>> Java
>>>>>  >>>>>>>>>>> heap and
>>>>>  >>>>>>>>>>> the metaspace.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> The new class metaspace allocation code tries to allocate
>>>>>  >>>>>>>>>>> memory at
>>>>>  >>>>>>>>>>> 32G,
>>>>>  >>>>>>>>>>> or above the CDS region, if it is present. Because of this,
>>>>>  >>>>>>>>>>> encoding
>>>>>  >>>>>>>>>>> and decoding of compressed klass pointers will always
>>>>>  >>>>>>>>>>> require use
>>>>>  >>>>>>>>>>> of a
>>>>>  >>>>>>>>>>> base register. So, encoding and decoding of compressed
>>>>> klass
>>>>>  >>>>>>>>>>> pointers
>>>>>  >>>>>>>>>>> will differ from compressed oops.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> There are no class metaspace allocation changes if
>>>>>  >>>>>>>>>>> UseCompressedKlassPointers is turned off or if running on a
>>>>>  >>>>>>>>>>> 32-bit
>>>>>  >>>>>>>>>>> platform.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> The code changes also include some cleanup and will fix
>>>>> bugs
>>>>>  >>>>>>>>>>> 8016729,
>>>>>  >>>>>>>>>>> 8011610, and 8003424.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Many of the modules in this webrev contain a lot of
>>>>> changes.
>>>>>  >>>>>>>>>>> Modules
>>>>>  >>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>>>>  >>>>>>>>>>> changed to
>>>>>  >>>>>>>>>>> support the new encoding and decoding of compressed klass
>>>>>  >>>>>>>>>>> pointers.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Module metaspace.cpp was changed significantly to support
>>>>>  >>>>>>>>>>> the new
>>>>>  >>>>>>>>>>> allocation for metaspace and the CDS region and to
>>>>> determine
>>>>>  >>>>>>>>>>> compressed
>>>>>  >>>>>>>>>>> klass pointer encoding base and shifting values.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Most of the changes to module universe.cpp were to
>>>>> remove code
>>>>>  >>>>>>>>>>> related
>>>>>  >>>>>>>>>>> to allocating metaspace and remove code that considered
>>>>>  >>>>>>>>>>> compressed
>>>>>  >>>>>>>>>>> klass
>>>>>  >>>>>>>>>>> pointers when determining the compressed oops compression
>>>>>  >>>>>>>>>>> mechanism.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were changed as
>>>>>  >>>>>>>>>>> part
>>>>>  >>>>>>>>>>> of a
>>>>>  >>>>>>>>>>> cleanup requested by Coleen.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> These changes were tested with JCK Lang and VM tests, JTReg
>>>>>  >>>>>>>>>>> tests,
>>>>>  >>>>>>>>>>> JPRT,
>>>>>  >>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and
>>>>>  >>>>>>>>>>> vm.mlvm.testlist
>>>>>  >>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and
>>>>>  >>>>>>>>>>> -Xshare:off
>>>>>  >>>>>>>>>>> (with
>>>>>  >>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit
>>>>>  >>>>>>>>>>> Linux and
>>>>>  >>>>>>>>>>> 64-Bit
>>>>>  >>>>>>>>>>> Linux.  Jtreg tests were run on Windows 7 and Mac OS.
>>>>> JCK tests
>>>>>  >>>>>>>>>>> were
>>>>>  >>>>>>>>>>> run on Solaris x86.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> The performance impact of these changes is TBD.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Thanks, Harold
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>
>>>>>  >>>>>>
>>>>>  >>>>
>>>>>  >>
>>>>>
>>>
>

From john.coomes at oracle.com  Thu Aug 15 11:53:06 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 18:53:06 +0000
Subject: hg: hsx/hotspot-emb/corba: 4 new changesets
Message-ID: <20130815185312.49C94488F4@hg.openjdk.java.net>

Changeset: cc11a0efb4f9
Author:    aefimov
Date:      2013-08-01 14:59 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/cc11a0efb4f9

8015987: The corba repo contains unneeded .sjava files
Reviewed-by: alanb, chegar, coffeys

- src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava
- src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava
- src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava
- src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava
- src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava
- src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava
- src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava
- src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava
- src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava
- src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava
- src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava

Changeset: 342a954b68f3
Author:    lana
Date:      2013-08-06 16:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/342a954b68f3

Merge


Changeset: 49c4a777fdfd
Author:    lana
Date:      2013-08-13 10:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/49c4a777fdfd

Merge


Changeset: d411c60a8c2f
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/d411c60a8c2f

Added tag jdk8-b103 for changeset 49c4a777fdfd

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 11:52:56 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 18:52:56 +0000
Subject: hg: hsx/hotspot-emb: Added tag jdk8-b103 for changeset b7e64be81c8a
Message-ID: <20130815185256.351B0488F3@hg.openjdk.java.net>

Changeset: ceefd94ef326
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/ceefd94ef326

Added tag jdk8-b103 for changeset b7e64be81c8a

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 11:53:27 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 18:53:27 +0000
Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b103 for changeset
	b1ceab582fc6
Message-ID: <20130815185337.7658A488F5@hg.openjdk.java.net>

Changeset: a22fe9bd01e6
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/a22fe9bd01e6

Added tag jdk8-b103 for changeset b1ceab582fc6

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 11:53:49 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 18:53:49 +0000
Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b103 for changeset
	6cdc6ed98780
Message-ID: <20130815185357.A78EA488F6@hg.openjdk.java.net>

Changeset: 42211ab0ab1c
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/42211ab0ab1c

Added tag jdk8-b103 for changeset 6cdc6ed98780

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 11:56:39 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 18:56:39 +0000
Subject: hg: hsx/hotspot-emb/jdk: 64 new changesets
Message-ID: <20130815191213.4E1CC488F9@hg.openjdk.java.net>

Changeset: 1c6bfb303ffc
Author:    prr
Date:      2013-08-06 13:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1c6bfb303ffc

8022175: Fix doclint warnings in javax.print
Reviewed-by: darcy

! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/MultiDocPrintJob.java
! src/share/classes/javax/print/PrintService.java
! src/share/classes/javax/print/ServiceUI.java
! src/share/classes/javax/print/ServiceUIFactory.java
! src/share/classes/javax/print/attribute/AttributeSet.java
! src/share/classes/javax/print/attribute/DateTimeSyntax.java
! src/share/classes/javax/print/attribute/DocAttributeSet.java
! src/share/classes/javax/print/attribute/EnumSyntax.java
! src/share/classes/javax/print/attribute/HashAttributeSet.java
! src/share/classes/javax/print/attribute/IntegerSyntax.java
! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java
! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java
! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java
! src/share/classes/javax/print/attribute/ResolutionSyntax.java
! src/share/classes/javax/print/attribute/Size2DSyntax.java
! src/share/classes/javax/print/attribute/standard/Chromaticity.java
! src/share/classes/javax/print/attribute/standard/Compression.java
! src/share/classes/javax/print/attribute/standard/Finishings.java
! src/share/classes/javax/print/attribute/standard/JobKOctets.java
! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java
! src/share/classes/javax/print/attribute/standard/MediaSize.java
! src/share/classes/javax/print/attribute/standard/PresentationDirection.java
! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java
! src/share/classes/javax/print/attribute/standard/PrinterResolution.java

Changeset: c3b91dc2504a
Author:    jgodinez
Date:      2013-08-06 14:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c3b91dc2504a

8021583: test/javax/print/autosense/PrintAutoSenseData.java throwing NPE
Reviewed-by: jchen, prr

! src/solaris/classes/sun/print/UnixPrintJob.java
! src/windows/classes/sun/print/Win32PrintJob.java
! test/javax/print/attribute/autosense/PrintAutoSenseData.java
+ test/javax/print/attribute/autosense/sample.txt

Changeset: fe04f40cf469
Author:    prr
Date:      2013-08-06 17:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fe04f40cf469

8022455: Fix doclint warnings in javax.imageio
Reviewed-by: darcy

! src/share/classes/javax/imageio/ImageIO.java
! src/share/classes/javax/imageio/ImageReadParam.java
! src/share/classes/javax/imageio/ImageReader.java
! src/share/classes/javax/imageio/ImageTypeSpecifier.java
! src/share/classes/javax/imageio/ImageWriteParam.java
! src/share/classes/javax/imageio/ImageWriter.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java
! src/share/classes/javax/imageio/spi/ImageReaderSpi.java
! src/share/classes/javax/imageio/spi/ImageWriterSpi.java
! src/share/classes/javax/imageio/spi/ServiceRegistry.java
! src/share/classes/javax/imageio/stream/ImageInputStream.java
! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java
! src/share/classes/javax/imageio/stream/ImageOutputStream.java

Changeset: c827ad8c1101
Author:    prr
Date:      2013-08-06 17:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c827ad8c1101

8022447: Fix doclint warnings in java.awt.image
Reviewed-by: darcy

! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ByteLookupTable.java
! src/share/classes/java/awt/image/ColorModel.java
! src/share/classes/java/awt/image/DirectColorModel.java
! src/share/classes/java/awt/image/ImageProducer.java
! src/share/classes/java/awt/image/IndexColorModel.java
! src/share/classes/java/awt/image/MemoryImageSource.java
! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/share/classes/java/awt/image/PixelGrabber.java
! src/share/classes/java/awt/image/RGBImageFilter.java
! src/share/classes/java/awt/image/ShortLookupTable.java
! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java
! src/share/classes/java/awt/image/WritableRaster.java

Changeset: 9314c199003d
Author:    lana
Date:      2013-08-06 22:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9314c199003d

Merge

- src/share/classes/java/net/package.html

Changeset: ab64c138d5bd
Author:    prr
Date:      2013-08-07 18:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ab64c138d5bd

8014883: java.awt.container.add(component comp object constraints) doesn't work as expected on some linux platforms
Reviewed-by: jgodinez

! makefiles/CompileNativeLibraries.gmk
! src/solaris/native/sun/java2d/x11/XRBackendNative.c

Changeset: 645a37a3559f
Author:    leonidr
Date:      2013-08-01 01:26 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/645a37a3559f

8021815: Add regression test for JDK-8007267
Reviewed-by: serb

+ test/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java

Changeset: 495ca130cbde
Author:    alexsch
Date:      2013-08-01 17:09 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/495ca130cbde

7161568: [macosx] api/javax_swing/JTabbedPane/index2.html#varios fails
Reviewed-by: malenkov, serb

! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
+ test/javax/swing/JTabbedPane/4361477/bug4361477.java
+ test/javax/swing/JTabbedPane/6495408/bug6495408.java
+ test/javax/swing/JTabbedPane/7161568/bug7161568.java

Changeset: e76b1568d002
Author:    leonidr
Date:      2013-08-02 15:42 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e76b1568d002

8021381: JavaFX scene included in Swing JDialog not starting from Web Start
Reviewed-by: art, dcherepanov

! src/share/classes/sun/awt/AppContext.java

Changeset: 07abddc1d7f2
Author:    leonidr
Date:      2013-08-06 17:07 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/07abddc1d7f2

8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE
Reviewed-by: art

! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java

Changeset: 27d1bdf2f7d9
Author:    mcherkas
Date:      2013-08-06 17:29 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/27d1bdf2f7d9

8016833: Underlines and strikethrough not rendering correctly
Reviewed-by: alexsch, serb
Contributed-by: anton.nashatyrev at oracle.com

! src/share/classes/javax/swing/text/GlyphView.java
+ test/javax/swing/text/StyledEditorKit/8016833/bug8016833.java

Changeset: f8ed88f5ed87
Author:    alexsch
Date:      2013-08-07 18:32 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f8ed88f5ed87

8022532: [parfait] Potential memory leak in gtk2_interface.c
Reviewed-by: art, serb

! src/solaris/native/sun/awt/gtk2_interface.c

Changeset: 7706a622d35f
Author:    alexsch
Date:      2013-08-07 18:58 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7706a622d35f

8013849: Awt assert on Hashtable.cpp:124
Reviewed-by: serb

! src/windows/native/sun/windows/awt_Component.cpp
+ test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java

Changeset: f70492d969e7
Author:    serb
Date:      2013-08-07 19:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f70492d969e7

7124339: [macosx] setIconImage is not endlessly tolerant to the broken image-arguments
Reviewed-by: alexsch, leonidr

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java

Changeset: 540192229a69
Author:    art
Date:      2013-08-07 21:31 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/540192229a69

6551589: ContainerListener Documentation may be incorrect
Reviewed-by: serb

! src/share/classes/java/awt/event/ContainerListener.java

Changeset: 9bcc3f2af980
Author:    lana
Date:      2013-08-07 12:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9bcc3f2af980

Merge

- src/share/classes/java/net/package.html

Changeset: e193c4ad940a
Author:    lana
Date:      2013-08-07 19:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e193c4ad940a

Merge


Changeset: c49b538ef054
Author:    chegar
Date:      2013-08-01 12:38 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c49b538ef054

8022061: More ProblemList.txt updates (7/2013)
Reviewed-by: alanb, psandoz

! test/ProblemList.txt

Changeset: 36f4cf8872f3
Author:    igerasim
Date:      2013-07-30 21:11 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/36f4cf8872f3

7192942: (coll) Inefficient calculation of power of two in HashMap
Reviewed-by: mduigou

! src/share/classes/java/util/HashMap.java

Changeset: 54329c24c2f4
Author:    igerasim
Date:      2013-07-29 12:35 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/54329c24c2f4

8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0
Reviewed-by: alanb, chegar, martin, rriggs

! src/share/classes/java/nio/file/Files.java
! test/java/nio/file/Files/BytesAndLines.java

Changeset: d6de149b9f20
Author:    xuelei
Date:      2013-08-01 07:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d6de149b9f20

7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java

Changeset: cd13a4a45a37
Author:    chegar
Date:      2013-08-01 16:53 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cd13a4a45a37

8022087: Fix doclint issues in j.u.Deque & Queue
Reviewed-by: chegar, darcy
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/Deque.java
! src/share/classes/java/util/Queue.java

Changeset: 0be7839d4599
Author:    psandoz
Date:      2013-08-01 15:28 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0be7839d4599

8020016: Numerous splitereator impls do not throw NPE for null Consumers
Reviewed-by: mduigou, alanb, henryjen

! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! src/share/classes/java/util/stream/Streams.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java

Changeset: 29f153e11683
Author:    weijun
Date:      2013-08-02 08:59 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/29f153e11683

8021789: jarsigner parses alias as command line option (depending on locale)
Reviewed-by: vinnie

! src/share/classes/sun/security/tools/jarsigner/Main.java
+ test/sun/security/tools/jarsigner/collator.sh

Changeset: 40221b09812f
Author:    uta
Date:      2013-08-02 13:16 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/40221b09812f

8020191: System.getProperty("os.name") returns "Windows NT (unknown)" on Windows 8.1
Reviewed-by: alanb, khazra, chegar

! src/windows/native/java/lang/java_props_md.c
! src/windows/resource/java.manifest

Changeset: 60c275e56a69
Author:    chegar
Date:      2013-08-02 11:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/60c275e56a69

8022121: Remove superfluous @test tag from SpliteratorTraversingAndSplittingTest
Reviewed-by: psandoz

! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

Changeset: 6ec910ff3ea1
Author:    chegar
Date:      2013-08-02 14:29 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6ec910ff3ea1

8020291: j.u.c.CompletionStage
8020435: CompletableFuture/Basic.java fails on single core machine
Reviewed-by: chegar, psandoz
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/concurrent/CompletableFuture.java
+ src/share/classes/java/util/concurrent/CompletionStage.java
! test/ProblemList.txt
! test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: 42b786f2fb99
Author:    mullan
Date:      2013-08-02 08:30 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/42b786f2fb99

8001319: Add SecurityPermission "insertProvider" target name
Reviewed-by: vinnie

! src/share/classes/java/security/Security.java
! src/share/classes/java/security/SecurityPermission.java
+ test/java/security/Security/AddProvider.java
+ test/java/security/Security/AddProvider.policy.1
+ test/java/security/Security/AddProvider.policy.2
+ test/java/security/Security/AddProvider.policy.3

Changeset: 7bbc6c2351d7
Author:    mullan
Date:      2013-08-02 08:37 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7bbc6c2351d7

Merge

- src/share/classes/java/net/package.html
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- test/java/util/Collections/EmptySortedSet.java

Changeset: 0a778e487a73
Author:    mullan
Date:      2013-08-02 09:38 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0a778e487a73

Merge


Changeset: 33617583c545
Author:    bpb
Date:      2013-07-31 10:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/33617583c545

6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion
Summary: Update specification to match implementation.
Reviewed-by: darcy
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! src/share/classes/java/util/Formatter.java
! test/java/util/Formatter/Basic-X.java.template
! test/java/util/Formatter/Basic.java
! test/java/util/Formatter/BasicDouble.java

Changeset: 883cc296ec89
Author:    bchristi
Date:      2013-08-02 15:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/883cc296ec89

8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X
Summary: On Mac, default to UTF-8 if no environmental hints are available
Reviewed-by: naoto, ddehaven

! src/solaris/native/java/lang/java_props_md.c
+ test/java/lang/System/MacEncoding/ExpectedEncoding.java
+ test/java/lang/System/MacEncoding/MacJNUEncoding.sh
+ test/java/lang/System/MacEncoding/TestFileEncoding.java
- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: dd1040690e31
Author:    bpb
Date:      2013-08-02 11:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/dd1040690e31

8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect
Summary: Fail test if errors; fix test values; port BigDecimal version to BigInteger
Reviewed-by: smarks, alanb
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! test/java/math/BigDecimal/CompareToTests.java
! test/java/math/BigInteger/CompareToTests.java

Changeset: 80da091343af
Author:    darcy
Date:      2013-08-05 07:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/80da091343af

8022190: Fix varargs lint warnings in the JDK
Reviewed-by: alanb, lancea, alexsch

! src/share/classes/java/util/stream/Stream.java
! src/share/classes/javax/swing/SwingWorker.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
! src/share/classes/sun/swing/AccumulativeRunnable.java

Changeset: 87367a1c7f76
Author:    sundar
Date:      2013-08-05 21:31 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/87367a1c7f76

8016531: jconsole-plugin script demo does not work with nashorn
Reviewed-by: lagergren, hannesw
Contributed-by: rieberandreas at gmail.com

! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java
! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js
! src/share/sample/scripting/scriptpad/README.txt
! src/share/sample/scripting/scriptpad/src/resources/conc.js
! src/share/sample/scripting/scriptpad/src/resources/mm.js

Changeset: 31759750ff63
Author:    smarks
Date:      2013-08-05 19:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/31759750ff63

8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address
Reviewed-by: rgallard, alanb

! src/share/classes/java/rmi/server/RMISocketFactory.java
! src/share/classes/java/rmi/server/UnicastRemoteObject.java

Changeset: fce446b29577
Author:    dsamersoff
Date:      2013-08-06 14:04 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fce446b29577

8011038: sourceObj validation during desereliazation of RelationNotification should be relaxed
Summary: sourceObj could be set to null by setSource() relax a validation of deserialized object.
Reviewed-by: sjiang, skoivu, dfuchs

! src/share/classes/javax/management/relation/RelationNotification.java

Changeset: 6773af0dda02
Author:    chegar
Date:      2013-08-06 15:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6773af0dda02

8022344: Additional debug info for test/java/net/NetworkInterface/IndexTest.java
Reviewed-by: michaelm, alanb

! test/java/net/NetworkInterface/IndexTest.java

Changeset: 1f4af3e0447e
Author:    mullan
Date:      2013-08-06 08:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1f4af3e0447e

8022120: JCK test api/javax_xml/crypto/dsig/TransformService/index_ParamMethods fails
Summary: TransformService.init and marshalParams must throw NullPointerException when parent parameter is null
Reviewed-by: xuelei

! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java
+ test/javax/xml/crypto/dsig/TransformService/NullParent.java

Changeset: ba634b53f53a
Author:    mullan
Date:      2013-08-06 08:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ba634b53f53a

Merge


Changeset: cd0ea5563523
Author:    jfranck
Date:      2013-08-06 18:54 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cd0ea5563523

7184826: (reflect) Add support for Project Lambda concepts in core reflection
Reviewed-by: darcy, jfranck
Contributed-by: Amy Lu <amy.lu at oracle.com>

+ test/java/lang/reflect/DefaultStaticTest/DefaultStaticInvokeTest.java
+ test/java/lang/reflect/DefaultStaticTest/DefaultStaticTestData.java
+ test/java/lang/reflect/DefaultStaticTest/helper/Declared.java
+ test/java/lang/reflect/DefaultStaticTest/helper/Mod.java
! test/java/lang/reflect/Method/DefaultMethodModeling.java
! test/java/lang/reflect/Method/IsDefaultTest.java

Changeset: 98643f3ddf40
Author:    darcy
Date:      2013-08-06 13:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/98643f3ddf40

8022174: Fix doclint warnings in javax.sound
8022404: Fix doclint issues in java.applet
Reviewed-by: prr

! src/share/classes/java/applet/AppletContext.java
! src/share/classes/javax/sound/midi/MetaMessage.java
! src/share/classes/javax/sound/midi/MidiDevice.java
! src/share/classes/javax/sound/midi/MidiDeviceReceiver.java
! src/share/classes/javax/sound/midi/MidiDeviceTransmitter.java
! src/share/classes/javax/sound/midi/MidiFileFormat.java
! src/share/classes/javax/sound/midi/MidiMessage.java
! src/share/classes/javax/sound/midi/MidiSystem.java
! src/share/classes/javax/sound/midi/ShortMessage.java
! src/share/classes/javax/sound/midi/Synthesizer.java
! src/share/classes/javax/sound/midi/SysexMessage.java
! src/share/classes/javax/sound/midi/Track.java
! src/share/classes/javax/sound/sampled/AudioFileFormat.java
! src/share/classes/javax/sound/sampled/AudioFormat.java
! src/share/classes/javax/sound/sampled/AudioSystem.java
! src/share/classes/javax/sound/sampled/BooleanControl.java
! src/share/classes/javax/sound/sampled/Mixer.java
! src/share/classes/javax/sound/sampled/spi/FormatConversionProvider.java

Changeset: 12c1b78acf9a
Author:    lagergren
Date:      2013-08-06 12:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/12c1b78acf9a

8022412: Fixed warnings in java.util root, except for HashMap
Reviewed-by: mduigou, darcy
Contributed-by: marcus.lagergren at oracle.com

! src/share/classes/java/util/ArrayPrefixHelpers.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Comparator.java
! src/share/classes/java/util/Comparators.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/Vector.java
! src/share/classes/java/util/WeakHashMap.java

Changeset: 8112076ae424
Author:    juh
Date:      2013-08-06 13:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8112076ae424

8022439: Fix lint warnings in sun.security.ec
Reviewed-by: darcy

! src/share/classes/sun/security/ec/ECDSASignature.java

Changeset: 69cfd941aec2
Author:    juh
Date:      2013-08-06 14:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/69cfd941aec2

8022443: Fix lint warnings in sun.security.pkcs12
Reviewed-by: darcy

! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java

Changeset: 31e923842d49
Author:    smarks
Date:      2013-08-06 14:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/31e923842d49

8022440: suppress deprecation warnings in sun.rmi
Reviewed-by: mduigou

! src/share/classes/sun/rmi/runtime/Log.java
! src/share/classes/sun/rmi/server/ActivatableRef.java
! src/share/classes/sun/rmi/server/Dispatcher.java
! src/share/classes/sun/rmi/server/LoaderHandler.java
! src/share/classes/sun/rmi/server/UnicastRef.java
! src/share/classes/sun/rmi/server/UnicastServerRef.java
! src/share/classes/sun/rmi/server/Util.java
! src/share/classes/sun/rmi/transport/DGCImpl.java
! src/share/classes/sun/rmi/transport/StreamRemoteCall.java
! src/share/classes/sun/rmi/transport/Transport.java
! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java
! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java
! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java

Changeset: 4b8b811059db
Author:    dxu
Date:      2013-08-06 14:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4b8b811059db

8022410: Fix Javac Warnings in com.sun.security.auth Package
Reviewed-by: darcy

! src/share/classes/com/sun/security/auth/PolicyFile.java
! src/share/classes/com/sun/security/auth/SubjectCodeSource.java

Changeset: d5694d78ebc6
Author:    darcy
Date:      2013-08-06 16:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d5694d78ebc6

8022406: Fix doclint issues in java.beans
Reviewed-by: prr

! src/share/classes/java/beans/AppletInitializer.java
! src/share/classes/java/beans/Beans.java
! src/share/classes/java/beans/ConstructorProperties.java
! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/EventHandler.java
! src/share/classes/java/beans/Expression.java
! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/PersistenceDelegate.java
! src/share/classes/java/beans/PropertyChangeSupport.java
! src/share/classes/java/beans/PropertyDescriptor.java
! src/share/classes/java/beans/Transient.java
! src/share/classes/java/beans/VetoableChangeSupport.java
! src/share/classes/java/beans/beancontext/BeanContext.java
! src/share/classes/java/beans/beancontext/BeanContextChild.java
! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java
! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java
! src/share/classes/java/beans/beancontext/BeanContextServices.java
! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java
! src/share/classes/java/beans/beancontext/BeanContextSupport.java

Changeset: 939c3be6cc86
Author:    briangoetz
Date:      2013-06-28 16:26 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/939c3be6cc86

8015318: Extend Collector with 'finish' operation
Reviewed-by: mduigou
Contributed-by: brian.goetz at oracle.com

! src/share/classes/java/util/DoubleSummaryStatistics.java
! src/share/classes/java/util/IntSummaryStatistics.java
! src/share/classes/java/util/LongSummaryStatistics.java
! src/share/classes/java/util/StringJoiner.java
! src/share/classes/java/util/stream/Collector.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DelegatingStream.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/ReduceOps.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/package-info.java
! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
! test/jdk/lambda/MethodReferenceTestInstanceMethod.java
! test/jdk/lambda/separate/TestHarness.java

Changeset: 6cc8c2ad9804
Author:    darcy
Date:      2013-08-06 16:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6cc8c2ad9804

8022453: Fix doclint issues in javax.accessibility
Reviewed-by: prr

! src/share/classes/javax/accessibility/Accessible.java
! src/share/classes/javax/accessibility/AccessibleBundle.java
! src/share/classes/javax/accessibility/AccessibleExtendedTable.java
! src/share/classes/javax/accessibility/AccessibleRelationSet.java
! src/share/classes/javax/accessibility/AccessibleTable.java
! src/share/classes/javax/accessibility/AccessibleTableModelChange.java
! src/share/classes/javax/accessibility/AccessibleTextSequence.java
! src/share/classes/javax/accessibility/AccessibleValue.java

Changeset: 2bc9ce1aade5
Author:    lana
Date:      2013-08-06 17:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2bc9ce1aade5

Merge


Changeset: 7ab5f19a9a31
Author:    lana
Date:      2013-08-06 17:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7ab5f19a9a31

Merge


Changeset: e303c228bf31
Author:    henryjen
Date:      2013-08-06 17:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e303c228bf31

8022446: Fix serial warnings in java.util.stream
Reviewed-by: darcy

! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/FindOps.java
! src/share/classes/java/util/stream/ForEachOps.java
! src/share/classes/java/util/stream/MatchOps.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/ReduceOps.java
! src/share/classes/java/util/stream/SliceOps.java

Changeset: 1d21ff5c2b3f
Author:    dxu
Date:      2013-08-06 18:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1d21ff5c2b3f

8022478: Fix Warnings In sun.net.www.protocol.http Package
Reviewed-by: darcy

! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java
! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java

Changeset: e117fcdd2176
Author:    mduigou
Date:      2013-08-06 18:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e117fcdd2176

8022476: cleanup some raw types and unchecked warnings in java.util.stream
Reviewed-by: darcy
Contributed-by: mike.duigou at oracle.com, henry.jen at oracle.com

! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/ReduceOps.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SortedOps.java
! src/share/classes/java/util/stream/StreamSpliterators.java

Changeset: 906dd23334c1
Author:    weijun
Date:      2013-08-07 19:06 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/906dd23334c1

7151062: [macosx] SCDynamicStore prints error messages to stderr
Reviewed-by: xuelei

! src/macosx/native/java/util/SCDynamicStoreConfig.m

Changeset: 99f4319763a9
Author:    sundar
Date:      2013-08-07 18:16 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/99f4319763a9

8022483: Nashorn compatibility issues in jhat's OQL feature
Reviewed-by: lagergren, attila, hannesw

! src/share/classes/com/sun/tools/hat/resources/hat.js
! src/share/classes/com/sun/tools/hat/resources/oqlhelp.html

Changeset: 8c7cf4926157
Author:    xuelei
Date:      2013-08-07 06:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8c7cf4926157

8013809: deadlock in SSLSocketImpl between between write and close
Reviewed-by: wetmore

! src/share/classes/sun/security/ssl/SSLSocketImpl.java

Changeset: c1f129f62f36
Author:    lagergren
Date:      2013-08-07 08:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c1f129f62f36

8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools
Reviewed-by: darcy
Contributed-by: marcus.lagergren at oracle.com

! src/share/classes/java/net/SocketAddress.java
! src/share/classes/java/util/logging/XMLFormatter.java
! src/share/classes/sun/tools/jar/JarException.java

Changeset: d1c82d5bee3f
Author:    dxu
Date:      2013-08-07 12:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d1c82d5bee3f

8022554: Fix Warnings in sun.invoke.anon Package
Reviewed-by: darcy, mduigou, lancea

! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java

Changeset: 8c50c27418d3
Author:    smarks
Date:      2013-08-07 16:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8c50c27418d3

8022479: clean up warnings from sun.tools.asm
Reviewed-by: lancea, darcy

! src/share/classes/sun/tools/asm/Assembler.java
! src/share/classes/sun/tools/asm/ConstantPool.java
! src/share/classes/sun/tools/asm/Instruction.java
! src/share/classes/sun/tools/asm/SwitchData.java
! src/share/classes/sun/tools/asm/TryData.java

Changeset: 23e68a8e4b91
Author:    lana
Date:      2013-08-07 19:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/23e68a8e4b91

Merge

- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: e0f6039c0290
Author:    lana
Date:      2013-08-13 10:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e0f6039c0290

Merge


Changeset: f1d8d15bfcb5
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f1d8d15bfcb5

Added tag jdk8-b103 for changeset e0f6039c0290

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 12:15:23 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 19:15:23 +0000
Subject: hg: hsx/hotspot-emb/nashorn: 5 new changesets
Message-ID: <20130815191530.148CE488FB@hg.openjdk.java.net>

Changeset: 0ad00ae4fec6
Author:    hannesw
Date:      2013-08-01 12:23 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/0ad00ae4fec6

8020132: Big object literal with numerical keys exceeds method size
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java
! src/jdk/nashorn/internal/codegen/MapCreator.java
! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java
! src/jdk/nashorn/internal/objects/ArrayBufferView.java
! src/jdk/nashorn/internal/runtime/NashornLoader.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java
+ test/script/basic/JDK-8020132.js
+ test/script/basic/JDK-8020132.js.EXPECTED

Changeset: bb0f3c896cb7
Author:    sundar
Date:      2013-08-06 13:10 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/bb0f3c896cb7

Merge


Changeset: ab90c566272d
Author:    lana
Date:      2013-08-06 17:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/ab90c566272d

Merge


Changeset: 414203de4374
Author:    lana
Date:      2013-08-13 10:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/414203de4374

Merge


Changeset: afc100513451
Author:    cl
Date:      2013-08-15 09:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/afc100513451

Added tag jdk8-b103 for changeset 414203de4374

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 12:14:26 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 19:14:26 +0000
Subject: hg: hsx/hotspot-emb/langtools: 11 new changesets
Message-ID: <20130815191510.21EB5488FA@hg.openjdk.java.net>

Changeset: 05370ef9dccb
Author:    ksrini
Date:      2013-07-31 08:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/05370ef9dccb

8014826: c.s.t.javac.tree.Pretty.visitNewArray() prints duplicate dimension markers
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/tree/Pretty.java
+ test/tools/javac/tree/NewArrayPretty.java

Changeset: 99b60bcf3862
Author:    vromero
Date:      2013-08-06 15:08 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/99b60bcf3862

8022186: javac generates dead code if a try with an empty body has a finalizer
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/T8022186/DeadCodeGeneratedForEmptyTryTest.java

Changeset: 051e64d0816e
Author:    jfranck
Date:      2013-08-07 01:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/051e64d0816e

8009367: Wrong kind of name used in comparison in javax.lang.model code for repeatable annotations
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java
+ test/tools/javac/processing/model/element/8009367/TestQualifiedNameUsed.java
+ test/tools/javac/processing/model/element/8009367/p/Q.java
+ test/tools/javac/processing/model/element/8009367/p/QQ.java
+ test/tools/javac/processing/model/element/8009367/p/R.java
+ test/tools/javac/processing/model/element/8009367/p/RR.java

Changeset: f3ea20a6e958
Author:    lana
Date:      2013-08-06 17:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f3ea20a6e958

Merge


Changeset: b926dc251be8
Author:    lana
Date:      2013-08-06 17:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/b926dc251be8

Merge


Changeset: f3deeccbf4cf
Author:    vromero
Date:      2013-08-07 10:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f3deeccbf4cf

8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations
Reviewed-by: jjg, jfranck

! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
+ test/tools/javac/T8020997/CannotCompileRepeatedAnnoTest.java

Changeset: c7dcf899ffff
Author:    vromero
Date:      2013-08-07 11:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/c7dcf899ffff

8008274: javac should not reference/use sample code
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/Main.java

Changeset: 8c55df2442c1
Author:    bpatel
Date:      2013-08-07 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/8c55df2442c1

7198274: RFE : Javadoc Accessibility : Use CSS styles rather than <strong> or <i> tags
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java
! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java
! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/com/sun/javadoc/testInterface/TestInterface.java
! test/com/sun/javadoc/testJavaFX/TestJavaFX.java
! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java
! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java
! test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java
! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java
! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java

Changeset: 33294f02c9a5
Author:    bpatel
Date:      2013-08-07 16:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/33294f02c9a5

4749567: stddoclet: Add CSS style for setting header/footer to be italic
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
+ test/com/sun/javadoc/testOptions/TestOptions.java
+ test/com/sun/javadoc/testOptions/pkg/Foo.java

Changeset: 76cfe7c61f25
Author:    lana
Date:      2013-08-13 10:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/76cfe7c61f25

Merge


Changeset: dd4a00c220c6
Author:    cl
Date:      2013-08-15 09:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/dd4a00c220c6

Added tag jdk8-b103 for changeset 76cfe7c61f25

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 12:47:45 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 19:47:45 +0000
Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b103 for changeset
	b1ceab582fc6
Message-ID: <20130815194756.ED8144890C@hg.openjdk.java.net>

Changeset: a22fe9bd01e6
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/a22fe9bd01e6

Added tag jdk8-b103 for changeset b1ceab582fc6

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 12:47:25 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 19:47:25 +0000
Subject: hg: hsx/hotspot-rt: Added tag jdk8-b103 for changeset b7e64be81c8a
Message-ID: <20130815194725.A955E4890A@hg.openjdk.java.net>

Changeset: ceefd94ef326
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/ceefd94ef326

Added tag jdk8-b103 for changeset b7e64be81c8a

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 12:47:32 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 19:47:32 +0000
Subject: hg: hsx/hotspot-rt/corba: 4 new changesets
Message-ID: <20130815194737.A08AB4890B@hg.openjdk.java.net>

Changeset: cc11a0efb4f9
Author:    aefimov
Date:      2013-08-01 14:59 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/cc11a0efb4f9

8015987: The corba repo contains unneeded .sjava files
Reviewed-by: alanb, chegar, coffeys

- src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava
- src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava
- src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava
- src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava
- src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava
- src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava
- src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava
- src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava
- src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava
- src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava
- src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava

Changeset: 342a954b68f3
Author:    lana
Date:      2013-08-06 16:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/342a954b68f3

Merge


Changeset: 49c4a777fdfd
Author:    lana
Date:      2013-08-13 10:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/49c4a777fdfd

Merge


Changeset: d411c60a8c2f
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/d411c60a8c2f

Added tag jdk8-b103 for changeset 49c4a777fdfd

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 12:48:07 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 19:48:07 +0000
Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b103 for changeset
	6cdc6ed98780
Message-ID: <20130815194816.26FB14890D@hg.openjdk.java.net>

Changeset: 42211ab0ab1c
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/42211ab0ab1c

Added tag jdk8-b103 for changeset 6cdc6ed98780

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 12:50:36 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 19:50:36 +0000
Subject: hg: hsx/hotspot-rt/jdk: 64 new changesets
Message-ID: <20130815200448.0608F4890F@hg.openjdk.java.net>

Changeset: 1c6bfb303ffc
Author:    prr
Date:      2013-08-06 13:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1c6bfb303ffc

8022175: Fix doclint warnings in javax.print
Reviewed-by: darcy

! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/MultiDocPrintJob.java
! src/share/classes/javax/print/PrintService.java
! src/share/classes/javax/print/ServiceUI.java
! src/share/classes/javax/print/ServiceUIFactory.java
! src/share/classes/javax/print/attribute/AttributeSet.java
! src/share/classes/javax/print/attribute/DateTimeSyntax.java
! src/share/classes/javax/print/attribute/DocAttributeSet.java
! src/share/classes/javax/print/attribute/EnumSyntax.java
! src/share/classes/javax/print/attribute/HashAttributeSet.java
! src/share/classes/javax/print/attribute/IntegerSyntax.java
! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java
! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java
! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java
! src/share/classes/javax/print/attribute/ResolutionSyntax.java
! src/share/classes/javax/print/attribute/Size2DSyntax.java
! src/share/classes/javax/print/attribute/standard/Chromaticity.java
! src/share/classes/javax/print/attribute/standard/Compression.java
! src/share/classes/javax/print/attribute/standard/Finishings.java
! src/share/classes/javax/print/attribute/standard/JobKOctets.java
! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java
! src/share/classes/javax/print/attribute/standard/MediaSize.java
! src/share/classes/javax/print/attribute/standard/PresentationDirection.java
! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java
! src/share/classes/javax/print/attribute/standard/PrinterResolution.java

Changeset: c3b91dc2504a
Author:    jgodinez
Date:      2013-08-06 14:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c3b91dc2504a

8021583: test/javax/print/autosense/PrintAutoSenseData.java throwing NPE
Reviewed-by: jchen, prr

! src/solaris/classes/sun/print/UnixPrintJob.java
! src/windows/classes/sun/print/Win32PrintJob.java
! test/javax/print/attribute/autosense/PrintAutoSenseData.java
+ test/javax/print/attribute/autosense/sample.txt

Changeset: fe04f40cf469
Author:    prr
Date:      2013-08-06 17:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fe04f40cf469

8022455: Fix doclint warnings in javax.imageio
Reviewed-by: darcy

! src/share/classes/javax/imageio/ImageIO.java
! src/share/classes/javax/imageio/ImageReadParam.java
! src/share/classes/javax/imageio/ImageReader.java
! src/share/classes/javax/imageio/ImageTypeSpecifier.java
! src/share/classes/javax/imageio/ImageWriteParam.java
! src/share/classes/javax/imageio/ImageWriter.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java
! src/share/classes/javax/imageio/spi/ImageReaderSpi.java
! src/share/classes/javax/imageio/spi/ImageWriterSpi.java
! src/share/classes/javax/imageio/spi/ServiceRegistry.java
! src/share/classes/javax/imageio/stream/ImageInputStream.java
! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java
! src/share/classes/javax/imageio/stream/ImageOutputStream.java

Changeset: c827ad8c1101
Author:    prr
Date:      2013-08-06 17:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c827ad8c1101

8022447: Fix doclint warnings in java.awt.image
Reviewed-by: darcy

! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ByteLookupTable.java
! src/share/classes/java/awt/image/ColorModel.java
! src/share/classes/java/awt/image/DirectColorModel.java
! src/share/classes/java/awt/image/ImageProducer.java
! src/share/classes/java/awt/image/IndexColorModel.java
! src/share/classes/java/awt/image/MemoryImageSource.java
! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/share/classes/java/awt/image/PixelGrabber.java
! src/share/classes/java/awt/image/RGBImageFilter.java
! src/share/classes/java/awt/image/ShortLookupTable.java
! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java
! src/share/classes/java/awt/image/WritableRaster.java

Changeset: 9314c199003d
Author:    lana
Date:      2013-08-06 22:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9314c199003d

Merge

- src/share/classes/java/net/package.html

Changeset: ab64c138d5bd
Author:    prr
Date:      2013-08-07 18:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ab64c138d5bd

8014883: java.awt.container.add(component comp object constraints) doesn't work as expected on some linux platforms
Reviewed-by: jgodinez

! makefiles/CompileNativeLibraries.gmk
! src/solaris/native/sun/java2d/x11/XRBackendNative.c

Changeset: 645a37a3559f
Author:    leonidr
Date:      2013-08-01 01:26 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/645a37a3559f

8021815: Add regression test for JDK-8007267
Reviewed-by: serb

+ test/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java

Changeset: 495ca130cbde
Author:    alexsch
Date:      2013-08-01 17:09 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/495ca130cbde

7161568: [macosx] api/javax_swing/JTabbedPane/index2.html#varios fails
Reviewed-by: malenkov, serb

! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
+ test/javax/swing/JTabbedPane/4361477/bug4361477.java
+ test/javax/swing/JTabbedPane/6495408/bug6495408.java
+ test/javax/swing/JTabbedPane/7161568/bug7161568.java

Changeset: e76b1568d002
Author:    leonidr
Date:      2013-08-02 15:42 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e76b1568d002

8021381: JavaFX scene included in Swing JDialog not starting from Web Start
Reviewed-by: art, dcherepanov

! src/share/classes/sun/awt/AppContext.java

Changeset: 07abddc1d7f2
Author:    leonidr
Date:      2013-08-06 17:07 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/07abddc1d7f2

8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE
Reviewed-by: art

! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java

Changeset: 27d1bdf2f7d9
Author:    mcherkas
Date:      2013-08-06 17:29 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/27d1bdf2f7d9

8016833: Underlines and strikethrough not rendering correctly
Reviewed-by: alexsch, serb
Contributed-by: anton.nashatyrev at oracle.com

! src/share/classes/javax/swing/text/GlyphView.java
+ test/javax/swing/text/StyledEditorKit/8016833/bug8016833.java

Changeset: f8ed88f5ed87
Author:    alexsch
Date:      2013-08-07 18:32 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f8ed88f5ed87

8022532: [parfait] Potential memory leak in gtk2_interface.c
Reviewed-by: art, serb

! src/solaris/native/sun/awt/gtk2_interface.c

Changeset: 7706a622d35f
Author:    alexsch
Date:      2013-08-07 18:58 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7706a622d35f

8013849: Awt assert on Hashtable.cpp:124
Reviewed-by: serb

! src/windows/native/sun/windows/awt_Component.cpp
+ test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java

Changeset: f70492d969e7
Author:    serb
Date:      2013-08-07 19:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f70492d969e7

7124339: [macosx] setIconImage is not endlessly tolerant to the broken image-arguments
Reviewed-by: alexsch, leonidr

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java

Changeset: 540192229a69
Author:    art
Date:      2013-08-07 21:31 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/540192229a69

6551589: ContainerListener Documentation may be incorrect
Reviewed-by: serb

! src/share/classes/java/awt/event/ContainerListener.java

Changeset: 9bcc3f2af980
Author:    lana
Date:      2013-08-07 12:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9bcc3f2af980

Merge

- src/share/classes/java/net/package.html

Changeset: e193c4ad940a
Author:    lana
Date:      2013-08-07 19:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e193c4ad940a

Merge


Changeset: c49b538ef054
Author:    chegar
Date:      2013-08-01 12:38 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c49b538ef054

8022061: More ProblemList.txt updates (7/2013)
Reviewed-by: alanb, psandoz

! test/ProblemList.txt

Changeset: 36f4cf8872f3
Author:    igerasim
Date:      2013-07-30 21:11 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/36f4cf8872f3

7192942: (coll) Inefficient calculation of power of two in HashMap
Reviewed-by: mduigou

! src/share/classes/java/util/HashMap.java

Changeset: 54329c24c2f4
Author:    igerasim
Date:      2013-07-29 12:35 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/54329c24c2f4

8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0
Reviewed-by: alanb, chegar, martin, rriggs

! src/share/classes/java/nio/file/Files.java
! test/java/nio/file/Files/BytesAndLines.java

Changeset: d6de149b9f20
Author:    xuelei
Date:      2013-08-01 07:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d6de149b9f20

7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java

Changeset: cd13a4a45a37
Author:    chegar
Date:      2013-08-01 16:53 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cd13a4a45a37

8022087: Fix doclint issues in j.u.Deque & Queue
Reviewed-by: chegar, darcy
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/Deque.java
! src/share/classes/java/util/Queue.java

Changeset: 0be7839d4599
Author:    psandoz
Date:      2013-08-01 15:28 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0be7839d4599

8020016: Numerous splitereator impls do not throw NPE for null Consumers
Reviewed-by: mduigou, alanb, henryjen

! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! src/share/classes/java/util/stream/Streams.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java

Changeset: 29f153e11683
Author:    weijun
Date:      2013-08-02 08:59 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/29f153e11683

8021789: jarsigner parses alias as command line option (depending on locale)
Reviewed-by: vinnie

! src/share/classes/sun/security/tools/jarsigner/Main.java
+ test/sun/security/tools/jarsigner/collator.sh

Changeset: 40221b09812f
Author:    uta
Date:      2013-08-02 13:16 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/40221b09812f

8020191: System.getProperty("os.name") returns "Windows NT (unknown)" on Windows 8.1
Reviewed-by: alanb, khazra, chegar

! src/windows/native/java/lang/java_props_md.c
! src/windows/resource/java.manifest

Changeset: 60c275e56a69
Author:    chegar
Date:      2013-08-02 11:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/60c275e56a69

8022121: Remove superfluous @test tag from SpliteratorTraversingAndSplittingTest
Reviewed-by: psandoz

! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

Changeset: 6ec910ff3ea1
Author:    chegar
Date:      2013-08-02 14:29 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6ec910ff3ea1

8020291: j.u.c.CompletionStage
8020435: CompletableFuture/Basic.java fails on single core machine
Reviewed-by: chegar, psandoz
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/concurrent/CompletableFuture.java
+ src/share/classes/java/util/concurrent/CompletionStage.java
! test/ProblemList.txt
! test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: 42b786f2fb99
Author:    mullan
Date:      2013-08-02 08:30 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/42b786f2fb99

8001319: Add SecurityPermission "insertProvider" target name
Reviewed-by: vinnie

! src/share/classes/java/security/Security.java
! src/share/classes/java/security/SecurityPermission.java
+ test/java/security/Security/AddProvider.java
+ test/java/security/Security/AddProvider.policy.1
+ test/java/security/Security/AddProvider.policy.2
+ test/java/security/Security/AddProvider.policy.3

Changeset: 7bbc6c2351d7
Author:    mullan
Date:      2013-08-02 08:37 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7bbc6c2351d7

Merge

- src/share/classes/java/net/package.html
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- test/java/util/Collections/EmptySortedSet.java

Changeset: 0a778e487a73
Author:    mullan
Date:      2013-08-02 09:38 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0a778e487a73

Merge


Changeset: 33617583c545
Author:    bpb
Date:      2013-07-31 10:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/33617583c545

6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion
Summary: Update specification to match implementation.
Reviewed-by: darcy
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! src/share/classes/java/util/Formatter.java
! test/java/util/Formatter/Basic-X.java.template
! test/java/util/Formatter/Basic.java
! test/java/util/Formatter/BasicDouble.java

Changeset: 883cc296ec89
Author:    bchristi
Date:      2013-08-02 15:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/883cc296ec89

8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X
Summary: On Mac, default to UTF-8 if no environmental hints are available
Reviewed-by: naoto, ddehaven

! src/solaris/native/java/lang/java_props_md.c
+ test/java/lang/System/MacEncoding/ExpectedEncoding.java
+ test/java/lang/System/MacEncoding/MacJNUEncoding.sh
+ test/java/lang/System/MacEncoding/TestFileEncoding.java
- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: dd1040690e31
Author:    bpb
Date:      2013-08-02 11:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dd1040690e31

8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect
Summary: Fail test if errors; fix test values; port BigDecimal version to BigInteger
Reviewed-by: smarks, alanb
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! test/java/math/BigDecimal/CompareToTests.java
! test/java/math/BigInteger/CompareToTests.java

Changeset: 80da091343af
Author:    darcy
Date:      2013-08-05 07:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/80da091343af

8022190: Fix varargs lint warnings in the JDK
Reviewed-by: alanb, lancea, alexsch

! src/share/classes/java/util/stream/Stream.java
! src/share/classes/javax/swing/SwingWorker.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
! src/share/classes/sun/swing/AccumulativeRunnable.java

Changeset: 87367a1c7f76
Author:    sundar
Date:      2013-08-05 21:31 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/87367a1c7f76

8016531: jconsole-plugin script demo does not work with nashorn
Reviewed-by: lagergren, hannesw
Contributed-by: rieberandreas at gmail.com

! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java
! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js
! src/share/sample/scripting/scriptpad/README.txt
! src/share/sample/scripting/scriptpad/src/resources/conc.js
! src/share/sample/scripting/scriptpad/src/resources/mm.js

Changeset: 31759750ff63
Author:    smarks
Date:      2013-08-05 19:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/31759750ff63

8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address
Reviewed-by: rgallard, alanb

! src/share/classes/java/rmi/server/RMISocketFactory.java
! src/share/classes/java/rmi/server/UnicastRemoteObject.java

Changeset: fce446b29577
Author:    dsamersoff
Date:      2013-08-06 14:04 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fce446b29577

8011038: sourceObj validation during desereliazation of RelationNotification should be relaxed
Summary: sourceObj could be set to null by setSource() relax a validation of deserialized object.
Reviewed-by: sjiang, skoivu, dfuchs

! src/share/classes/javax/management/relation/RelationNotification.java

Changeset: 6773af0dda02
Author:    chegar
Date:      2013-08-06 15:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6773af0dda02

8022344: Additional debug info for test/java/net/NetworkInterface/IndexTest.java
Reviewed-by: michaelm, alanb

! test/java/net/NetworkInterface/IndexTest.java

Changeset: 1f4af3e0447e
Author:    mullan
Date:      2013-08-06 08:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1f4af3e0447e

8022120: JCK test api/javax_xml/crypto/dsig/TransformService/index_ParamMethods fails
Summary: TransformService.init and marshalParams must throw NullPointerException when parent parameter is null
Reviewed-by: xuelei

! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java
+ test/javax/xml/crypto/dsig/TransformService/NullParent.java

Changeset: ba634b53f53a
Author:    mullan
Date:      2013-08-06 08:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ba634b53f53a

Merge


Changeset: cd0ea5563523
Author:    jfranck
Date:      2013-08-06 18:54 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cd0ea5563523

7184826: (reflect) Add support for Project Lambda concepts in core reflection
Reviewed-by: darcy, jfranck
Contributed-by: Amy Lu <amy.lu at oracle.com>

+ test/java/lang/reflect/DefaultStaticTest/DefaultStaticInvokeTest.java
+ test/java/lang/reflect/DefaultStaticTest/DefaultStaticTestData.java
+ test/java/lang/reflect/DefaultStaticTest/helper/Declared.java
+ test/java/lang/reflect/DefaultStaticTest/helper/Mod.java
! test/java/lang/reflect/Method/DefaultMethodModeling.java
! test/java/lang/reflect/Method/IsDefaultTest.java

Changeset: 98643f3ddf40
Author:    darcy
Date:      2013-08-06 13:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/98643f3ddf40

8022174: Fix doclint warnings in javax.sound
8022404: Fix doclint issues in java.applet
Reviewed-by: prr

! src/share/classes/java/applet/AppletContext.java
! src/share/classes/javax/sound/midi/MetaMessage.java
! src/share/classes/javax/sound/midi/MidiDevice.java
! src/share/classes/javax/sound/midi/MidiDeviceReceiver.java
! src/share/classes/javax/sound/midi/MidiDeviceTransmitter.java
! src/share/classes/javax/sound/midi/MidiFileFormat.java
! src/share/classes/javax/sound/midi/MidiMessage.java
! src/share/classes/javax/sound/midi/MidiSystem.java
! src/share/classes/javax/sound/midi/ShortMessage.java
! src/share/classes/javax/sound/midi/Synthesizer.java
! src/share/classes/javax/sound/midi/SysexMessage.java
! src/share/classes/javax/sound/midi/Track.java
! src/share/classes/javax/sound/sampled/AudioFileFormat.java
! src/share/classes/javax/sound/sampled/AudioFormat.java
! src/share/classes/javax/sound/sampled/AudioSystem.java
! src/share/classes/javax/sound/sampled/BooleanControl.java
! src/share/classes/javax/sound/sampled/Mixer.java
! src/share/classes/javax/sound/sampled/spi/FormatConversionProvider.java

Changeset: 12c1b78acf9a
Author:    lagergren
Date:      2013-08-06 12:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/12c1b78acf9a

8022412: Fixed warnings in java.util root, except for HashMap
Reviewed-by: mduigou, darcy
Contributed-by: marcus.lagergren at oracle.com

! src/share/classes/java/util/ArrayPrefixHelpers.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Comparator.java
! src/share/classes/java/util/Comparators.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/Vector.java
! src/share/classes/java/util/WeakHashMap.java

Changeset: 8112076ae424
Author:    juh
Date:      2013-08-06 13:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8112076ae424

8022439: Fix lint warnings in sun.security.ec
Reviewed-by: darcy

! src/share/classes/sun/security/ec/ECDSASignature.java

Changeset: 69cfd941aec2
Author:    juh
Date:      2013-08-06 14:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/69cfd941aec2

8022443: Fix lint warnings in sun.security.pkcs12
Reviewed-by: darcy

! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java

Changeset: 31e923842d49
Author:    smarks
Date:      2013-08-06 14:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/31e923842d49

8022440: suppress deprecation warnings in sun.rmi
Reviewed-by: mduigou

! src/share/classes/sun/rmi/runtime/Log.java
! src/share/classes/sun/rmi/server/ActivatableRef.java
! src/share/classes/sun/rmi/server/Dispatcher.java
! src/share/classes/sun/rmi/server/LoaderHandler.java
! src/share/classes/sun/rmi/server/UnicastRef.java
! src/share/classes/sun/rmi/server/UnicastServerRef.java
! src/share/classes/sun/rmi/server/Util.java
! src/share/classes/sun/rmi/transport/DGCImpl.java
! src/share/classes/sun/rmi/transport/StreamRemoteCall.java
! src/share/classes/sun/rmi/transport/Transport.java
! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java
! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java
! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java

Changeset: 4b8b811059db
Author:    dxu
Date:      2013-08-06 14:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4b8b811059db

8022410: Fix Javac Warnings in com.sun.security.auth Package
Reviewed-by: darcy

! src/share/classes/com/sun/security/auth/PolicyFile.java
! src/share/classes/com/sun/security/auth/SubjectCodeSource.java

Changeset: d5694d78ebc6
Author:    darcy
Date:      2013-08-06 16:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d5694d78ebc6

8022406: Fix doclint issues in java.beans
Reviewed-by: prr

! src/share/classes/java/beans/AppletInitializer.java
! src/share/classes/java/beans/Beans.java
! src/share/classes/java/beans/ConstructorProperties.java
! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/EventHandler.java
! src/share/classes/java/beans/Expression.java
! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/PersistenceDelegate.java
! src/share/classes/java/beans/PropertyChangeSupport.java
! src/share/classes/java/beans/PropertyDescriptor.java
! src/share/classes/java/beans/Transient.java
! src/share/classes/java/beans/VetoableChangeSupport.java
! src/share/classes/java/beans/beancontext/BeanContext.java
! src/share/classes/java/beans/beancontext/BeanContextChild.java
! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java
! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java
! src/share/classes/java/beans/beancontext/BeanContextServices.java
! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java
! src/share/classes/java/beans/beancontext/BeanContextSupport.java

Changeset: 939c3be6cc86
Author:    briangoetz
Date:      2013-06-28 16:26 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/939c3be6cc86

8015318: Extend Collector with 'finish' operation
Reviewed-by: mduigou
Contributed-by: brian.goetz at oracle.com

! src/share/classes/java/util/DoubleSummaryStatistics.java
! src/share/classes/java/util/IntSummaryStatistics.java
! src/share/classes/java/util/LongSummaryStatistics.java
! src/share/classes/java/util/StringJoiner.java
! src/share/classes/java/util/stream/Collector.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DelegatingStream.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/ReduceOps.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/package-info.java
! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
! test/jdk/lambda/MethodReferenceTestInstanceMethod.java
! test/jdk/lambda/separate/TestHarness.java

Changeset: 6cc8c2ad9804
Author:    darcy
Date:      2013-08-06 16:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6cc8c2ad9804

8022453: Fix doclint issues in javax.accessibility
Reviewed-by: prr

! src/share/classes/javax/accessibility/Accessible.java
! src/share/classes/javax/accessibility/AccessibleBundle.java
! src/share/classes/javax/accessibility/AccessibleExtendedTable.java
! src/share/classes/javax/accessibility/AccessibleRelationSet.java
! src/share/classes/javax/accessibility/AccessibleTable.java
! src/share/classes/javax/accessibility/AccessibleTableModelChange.java
! src/share/classes/javax/accessibility/AccessibleTextSequence.java
! src/share/classes/javax/accessibility/AccessibleValue.java

Changeset: 2bc9ce1aade5
Author:    lana
Date:      2013-08-06 17:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2bc9ce1aade5

Merge


Changeset: 7ab5f19a9a31
Author:    lana
Date:      2013-08-06 17:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7ab5f19a9a31

Merge


Changeset: e303c228bf31
Author:    henryjen
Date:      2013-08-06 17:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e303c228bf31

8022446: Fix serial warnings in java.util.stream
Reviewed-by: darcy

! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/FindOps.java
! src/share/classes/java/util/stream/ForEachOps.java
! src/share/classes/java/util/stream/MatchOps.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/ReduceOps.java
! src/share/classes/java/util/stream/SliceOps.java

Changeset: 1d21ff5c2b3f
Author:    dxu
Date:      2013-08-06 18:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1d21ff5c2b3f

8022478: Fix Warnings In sun.net.www.protocol.http Package
Reviewed-by: darcy

! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java
! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java

Changeset: e117fcdd2176
Author:    mduigou
Date:      2013-08-06 18:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e117fcdd2176

8022476: cleanup some raw types and unchecked warnings in java.util.stream
Reviewed-by: darcy
Contributed-by: mike.duigou at oracle.com, henry.jen at oracle.com

! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/ReduceOps.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SortedOps.java
! src/share/classes/java/util/stream/StreamSpliterators.java

Changeset: 906dd23334c1
Author:    weijun
Date:      2013-08-07 19:06 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/906dd23334c1

7151062: [macosx] SCDynamicStore prints error messages to stderr
Reviewed-by: xuelei

! src/macosx/native/java/util/SCDynamicStoreConfig.m

Changeset: 99f4319763a9
Author:    sundar
Date:      2013-08-07 18:16 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/99f4319763a9

8022483: Nashorn compatibility issues in jhat's OQL feature
Reviewed-by: lagergren, attila, hannesw

! src/share/classes/com/sun/tools/hat/resources/hat.js
! src/share/classes/com/sun/tools/hat/resources/oqlhelp.html

Changeset: 8c7cf4926157
Author:    xuelei
Date:      2013-08-07 06:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8c7cf4926157

8013809: deadlock in SSLSocketImpl between between write and close
Reviewed-by: wetmore

! src/share/classes/sun/security/ssl/SSLSocketImpl.java

Changeset: c1f129f62f36
Author:    lagergren
Date:      2013-08-07 08:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c1f129f62f36

8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools
Reviewed-by: darcy
Contributed-by: marcus.lagergren at oracle.com

! src/share/classes/java/net/SocketAddress.java
! src/share/classes/java/util/logging/XMLFormatter.java
! src/share/classes/sun/tools/jar/JarException.java

Changeset: d1c82d5bee3f
Author:    dxu
Date:      2013-08-07 12:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d1c82d5bee3f

8022554: Fix Warnings in sun.invoke.anon Package
Reviewed-by: darcy, mduigou, lancea

! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java

Changeset: 8c50c27418d3
Author:    smarks
Date:      2013-08-07 16:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8c50c27418d3

8022479: clean up warnings from sun.tools.asm
Reviewed-by: lancea, darcy

! src/share/classes/sun/tools/asm/Assembler.java
! src/share/classes/sun/tools/asm/ConstantPool.java
! src/share/classes/sun/tools/asm/Instruction.java
! src/share/classes/sun/tools/asm/SwitchData.java
! src/share/classes/sun/tools/asm/TryData.java

Changeset: 23e68a8e4b91
Author:    lana
Date:      2013-08-07 19:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/23e68a8e4b91

Merge

- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: e0f6039c0290
Author:    lana
Date:      2013-08-13 10:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e0f6039c0290

Merge


Changeset: f1d8d15bfcb5
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f1d8d15bfcb5

Added tag jdk8-b103 for changeset e0f6039c0290

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 13:07:11 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 20:07:11 +0000
Subject: hg: hsx/hotspot-rt/langtools: 11 new changesets
Message-ID: <20130815200804.11CF548910@hg.openjdk.java.net>

Changeset: 05370ef9dccb
Author:    ksrini
Date:      2013-07-31 08:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/05370ef9dccb

8014826: c.s.t.javac.tree.Pretty.visitNewArray() prints duplicate dimension markers
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/tree/Pretty.java
+ test/tools/javac/tree/NewArrayPretty.java

Changeset: 99b60bcf3862
Author:    vromero
Date:      2013-08-06 15:08 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/99b60bcf3862

8022186: javac generates dead code if a try with an empty body has a finalizer
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/T8022186/DeadCodeGeneratedForEmptyTryTest.java

Changeset: 051e64d0816e
Author:    jfranck
Date:      2013-08-07 01:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/051e64d0816e

8009367: Wrong kind of name used in comparison in javax.lang.model code for repeatable annotations
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java
+ test/tools/javac/processing/model/element/8009367/TestQualifiedNameUsed.java
+ test/tools/javac/processing/model/element/8009367/p/Q.java
+ test/tools/javac/processing/model/element/8009367/p/QQ.java
+ test/tools/javac/processing/model/element/8009367/p/R.java
+ test/tools/javac/processing/model/element/8009367/p/RR.java

Changeset: f3ea20a6e958
Author:    lana
Date:      2013-08-06 17:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f3ea20a6e958

Merge


Changeset: b926dc251be8
Author:    lana
Date:      2013-08-06 17:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b926dc251be8

Merge


Changeset: f3deeccbf4cf
Author:    vromero
Date:      2013-08-07 10:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f3deeccbf4cf

8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations
Reviewed-by: jjg, jfranck

! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
+ test/tools/javac/T8020997/CannotCompileRepeatedAnnoTest.java

Changeset: c7dcf899ffff
Author:    vromero
Date:      2013-08-07 11:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c7dcf899ffff

8008274: javac should not reference/use sample code
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/Main.java

Changeset: 8c55df2442c1
Author:    bpatel
Date:      2013-08-07 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8c55df2442c1

7198274: RFE : Javadoc Accessibility : Use CSS styles rather than <strong> or <i> tags
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java
! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java
! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/com/sun/javadoc/testInterface/TestInterface.java
! test/com/sun/javadoc/testJavaFX/TestJavaFX.java
! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java
! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java
! test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java
! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java
! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java

Changeset: 33294f02c9a5
Author:    bpatel
Date:      2013-08-07 16:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/33294f02c9a5

4749567: stddoclet: Add CSS style for setting header/footer to be italic
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
+ test/com/sun/javadoc/testOptions/TestOptions.java
+ test/com/sun/javadoc/testOptions/pkg/Foo.java

Changeset: 76cfe7c61f25
Author:    lana
Date:      2013-08-13 10:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/76cfe7c61f25

Merge


Changeset: dd4a00c220c6
Author:    cl
Date:      2013-08-15 09:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/dd4a00c220c6

Added tag jdk8-b103 for changeset 76cfe7c61f25

! .hgtags


From john.coomes at oracle.com  Thu Aug 15 13:08:27 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 15 Aug 2013 20:08:27 +0000
Subject: hg: hsx/hotspot-rt/nashorn: 5 new changesets
Message-ID: <20130815200834.25FE748911@hg.openjdk.java.net>

Changeset: 0ad00ae4fec6
Author:    hannesw
Date:      2013-08-01 12:23 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/0ad00ae4fec6

8020132: Big object literal with numerical keys exceeds method size
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java
! src/jdk/nashorn/internal/codegen/MapCreator.java
! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java
! src/jdk/nashorn/internal/objects/ArrayBufferView.java
! src/jdk/nashorn/internal/runtime/NashornLoader.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java
+ test/script/basic/JDK-8020132.js
+ test/script/basic/JDK-8020132.js.EXPECTED

Changeset: bb0f3c896cb7
Author:    sundar
Date:      2013-08-06 13:10 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/bb0f3c896cb7

Merge


Changeset: ab90c566272d
Author:    lana
Date:      2013-08-06 17:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/ab90c566272d

Merge


Changeset: 414203de4374
Author:    lana
Date:      2013-08-13 10:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/414203de4374

Merge


Changeset: afc100513451
Author:    cl
Date:      2013-08-15 09:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/afc100513451

Added tag jdk8-b103 for changeset 414203de4374

! .hgtags


From coleen.phillimore at oracle.com  Thu Aug 15 13:31:50 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 15 Aug 2013 16:31:50 -0400
Subject: Request for review: 8003424 - Enable Class Data Sharing for
	CompressedOops
In-Reply-To: <520D146D.4070003@oracle.com>
References: <8a8c4ecb-c268-4380-9daf-96b627b56546@default>
	<520B4228.7000307@oracle.com> <520B758C.2080405@oracle.com>
	<520B7649.6080604@oracle.com> <520D146D.4070003@oracle.com>
Message-ID: <520D3AB6.3040607@oracle.com>


Looks good!

Thank you for all the adhoc test runs.   Also, thanks to SQE for running 
a special full PIT test run, and thanks to the performance team for 
running performance tests on this change also.

Coleen

On 08/15/2013 01:48 PM, harold seigel wrote:
> Hi,
>
> Please review this updated version of the fix for 8003424: 
> http://cr.openjdk.java.net/~hseigel/bug_8003424.4/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.4/>
>
> Other than removing an obsolete comment from universe.cpp, only the 
> tests have been changed since the previous webrev.  A few test errors 
> were fixed, '@run main' tags were added, and the handling of cases 
> where CDS cannot be used has been improved.
>
> Thanks, Harold
>
> On 8/14/2013 8:21 AM, Mikael Gerdin wrote:
>> Harold,
>>
>> On 2013-08-14 14:18, harold seigel wrote:
>>> Hi Mikael,
>>>
>>> Thanks for the review.
>>>
>>> In test CDSCompressedKPtrs.java, RuntimeException gets thrown by
>>> output.shouldContain(), if it does not find the specified text in the
>>> test's output.  In this test, it may not find "sharing" in the test
>>> output if the JVM was unable to compatibly allocate the class
>>> metaspace.  If the class metaspace does not get allocated near the CDS
>>> region then the JVM turns off CDS, disabling sharing.  Since this is a
>>> valid execution path, it shouldn't cause the test to fail.
>>>
>>> I've added a comment and changed the test a bit to try and make it 
>>> clearer:
>>>
>>>        } catch (RuntimeException e) {
>>>          // Report 'passed' if CDS was turned off because we could not
>>> allocate
>>>          // the klass metaspace at an address that would work with CDS.
>>>          output.shouldContain("Could not allocate metaspace at a
>>> compatible address");
>>>          output.shouldHaveExitValue(1);
>>>        }
>>
>> I see. I suspected that this was the case but it wasn't clear 
>> earlier. I think that the comment is sufficient to communicate this.
>>
>>
>> /Mikael
>>
>>>
>>> Thanks, Harold
>>>
>>> On 8/14/2013 4:39 AM, Mikael Gerdin wrote:
>>>> Harold,
>>>>
>>>> On 2013-08-09 16:57, Harold Seigel wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this latest version of the bug fix for 8003424:
>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.3/
>>>>>
>>>>>
>>>>> This new version includes the following changes:
>>>>>
>>>>> 1. macroAssembler_sparc.cpp
>>>>>
>>>>>     a. Merged two versions of reinit_heapbase() into one.
>>>>>
>>>>>     b. Improved decode_klass_not_null(src, dst) to not use G6 if
>>>>> shift == 0.
>>>>>
>>>>>
>>>>> 2. macroAssembler_x86.cpp
>>>>>
>>>>>     a. Merged two versions of reinit_heapbase() into one.
>>>>>
>>>>>     b. Improved encode_klass_not_null(src, dst) to not use R12.
>>>>>
>>>>>     c. Replaced leaq with addq in decode_klass_not_null(src, dst).
>>>>>
>>>>>
>>>>> 3. Improved variable names in heap.cpp.
>>>>>
>>>>>
>>>>> 4. metaspace.cpp
>>>>>
>>>>>     a. Rewrote MetaspaceAux::reserved_in_bytes() to make it more
>>>>> understandable.
>>>>>
>>>>>     b. Moved set_narrow_klass_base_and_shift() near
>>>>> can_use_cds_with_metaspace_addr().
>>>>>
>>>>>     c. Changed unneeded conditional in initialize_class_space() 
>>>>> into an
>>>>> assert.
>>>>>
>>>>>
>>>>> 5. arguments.cpp
>>>>>
>>>>>     a. Fixed problem with -Xshare:dump and disabled compression.
>>>>>
>>>>>     b. Moved UseCompressedKlassPointers code into new function:
>>>>> set_use_compressed_klass_ptrs().
>>>>>
>>>>>     c. Fixed bug 8005933 that turned off CDS for -server even if
>>>>> -Xshare:auto was explicitly specified.
>>>>>
>>>>>
>>>>> 6. Increased default value of ClassMetaspaceSize to 1*G in 
>>>>> globals.hpp.
>>>>>
>>>>>
>>>>> 7. Fixed indentation issues in metaspace.cpp and other modules.
>>>>
>>>> The VM changes look good to me.
>>>>
>>>> I have a question about the test CDSCompressedKPtrs.java
>>>>
>>>> What RuntimeException do you expect and why is it ok that we can't use
>>>> the shared archive if you get such an exception?
>>>>
>>>> I think at least a comment about why the test is supposed to pass even
>>>> if we can't use the shared archive.
>>>>
>>>> /Mikael
>>>>
>>>>>
>>>>>
>>>>> Thanks, Harold
>>>>>
>>>>> ----- Original Message -----
>>>>> From: harold.seigel at oracle.com
>>>>> To: coleen.phillimore at oracle.com
>>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>>> Sent: Friday, August 9, 2013 8:44:29 AM GMT -05:00 US/Canada Eastern
>>>>> Subject: Re: Request for review: 8003424 - Enable Class Data 
>>>>> Sharing for
>>>>> CompressedOops
>>>>>
>>>>> The purpose of this assert is to verify that the two methods in 
>>>>> the 'if'
>>>>> clause closed the map file and disabled UseSharedSpaces if they 
>>>>> detected
>>>>> a problem when trying to use CDS.
>>>>>
>>>>>        if (mapinfo->initialize() &&
>>>>> MetaspaceShared::map_shared_spaces(mapinfo)) {
>>>>>          FileMapInfo::set_current_info(mapinfo);
>>>>>        } else {
>>>>>          assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>>>                 "archive file not closed or shared spaces not
>>>>> disabled.");
>>>>>        }
>>>>>
>>>>> ----- Original Message -----
>>>>> From: harold.seigel at oracle.com
>>>>> To: coleen.phillimore at oracle.com
>>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>>> Sent: Friday, August 9, 2013 8:29:59 AM GMT -05:00 US/Canada Eastern
>>>>> Subject: Re: Request for review: 8003424 - Enable Class Data 
>>>>> Sharing for
>>>>> CompressedOops
>>>>>
>>>>> This is a bug that Stefan Karlsson also discovered.  To fix it, I've
>>>>> changed the code to this:
>>>>>
>>>>>    if (DumpSharedSpaces) {
>>>>>      if (RequireSharedSpaces) {
>>>>>        warning("cannot dump shared archive while using shared 
>>>>> archive");
>>>>>      }
>>>>>      UseSharedSpaces = false;
>>>>> #ifdef _LP64
>>>>>      if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>>        vm_exit_during_initialization(
>>>>>          "Cannot dump shared archive when UseCompressedOops or
>>>>> UseCompressedKlassPointers is off.", NULL);
>>>>>      }
>>>>>
>>>>> Harold
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: coleen.phillimore at oracle.com
>>>>> To: hotspot-runtime-dev at openjdk.java.net
>>>>> Sent: Thursday, August 8, 2013 7:08:15 PM GMT -05:00 US/Canada 
>>>>> Eastern
>>>>> Subject: Re: Request for review: 8003424 - Enable Class Data 
>>>>> Sharing for
>>>>> CompressedOops
>>>>>
>>>>>
>>>>> Yes, there should be a check for that too.  Now I'll really let 
>>>>> Harold
>>>>> answer.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 08/08/2013 06:55 PM, Vladimir Kozlov wrote:
>>>>>  > Coleen, Harold
>>>>>  >
>>>>>  > > The InstanceKlass has offsets to fields in the instance, and 
>>>>> they
>>>>>  > depend
>>>>>  > > on both compressed oops and compressed klass pointers.   So both
>>>>>  > have to
>>>>>  > > be on for the offsets to be valid.
>>>>>  >
>>>>>  > So there is dependency on UseCompressedOops and
>>>>>  > UseCompressedKlassPointers flags during dump.
>>>>>  >
>>>>>  > Then why the check is done only for UseSharedSpaces and not for
>>>>>  > DumpSharedSpaces?:
>>>>>  >
>>>>>  >     if (DumpSharedSpaces) {
>>>>>  >       if (RequireSharedSpaces) {
>>>>>  >         warning("cannot dump shared archive while using shared
>>>>> archive");
>>>>>  >       }
>>>>>  >       UseSharedSpaces = false;
>>>>>  > + #ifdef _LP64
>>>>>  > +   } else {
>>>>>  > +     // UseCompressedOops and UseCompressedKlassPointers must 
>>>>> be on
>>>>>  > for UseSharedSpaces.
>>>>>  > +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>>  > +       no_shared_spaces();
>>>>>  > +     }
>>>>>  > + #endif
>>>>>  >     }
>>>>>  >
>>>>>  > Thanks,
>>>>>  > Vladimir
>>>>>  >
>>>>>  > On 8/8/13 3:34 PM, Coleen Phillimore wrote:
>>>>>  >>
>>>>>  >> Hi Vladimir,
>>>>>  >>
>>>>>  >> I have a couple of answers and I'll let Harold answer the rest.
>>>>>  >>
>>>>>  >> On 08/08/2013 05:37 PM, Vladimir Kozlov wrote:
>>>>>  >>> On 8/7/13 8:34 AM, harold seigel wrote:
>>>>>  >>>> Hi Vladimir,
>>>>>  >>>>
>>>>>  >>>> On 8/5/2013 6:59 PM, Vladimir Kozlov wrote:
>>>>>  >>>>> Harold,
>>>>>  >>>>>
>>>>>  >>>>> Note, on SPARC set() could generate up to 8 instructions to 
>>>>> load
>>>>>  >>>>> 64-bit constant into register. So I am not sure that it 
>>>>> will be
>>>>>  >>>>> faster
>>>>>  >>>>> than load.
>>>>>  >>>> We thought it would be faster because it doesn't need to load
>>>>> anything
>>>>>  >>>> from memory.
>>>>>  >>>
>>>>>  >>> For good value (0x800000000) it should use only 2-3 
>>>>> instructions.
>>>>>  >>> I think you can keep using set().
>>>>>  >>>
>>>>>  >>>>>
>>>>>  >>>>> I can't find where in CDS you store information about 
>>>>> compressed
>>>>>  >>>>> klass
>>>>>  >>>>> pointers and compressed oops parameters which were used during
>>>>> dump?
>>>>>  >>>>> How you verify that correct parameters/flags are ussed when
>>>>> such CDS
>>>>>  >>>>> is used later?
>>>>>  >>>> No compressed klass pointers nor compressed oops get written to
>>>>> the
>>>>>  >>>> archive.  So, the compressed klass pointers and compressed oops
>>>>>  >>>> parameters do not need to be recorded in the archive.
>>>>>  >>>
>>>>>  >>> So you are saying that all klass pointers (references to
>>>>> klasses) in
>>>>>  >>> metadata structures in metaspace are full.
>>>>>  >>
>>>>>  >> Yes, they are.  (methodOops weren't in the
>>>>> InstanceKlass::_methods array
>>>>>  >> with Permgen but they are uncompressed now).
>>>>>  >>
>>>>>  >>> And klass pointers are only compressed in java object headers
>>>>> (which
>>>>>  >>> are not part of CDS). Right?
>>>>>  >>
>>>>>  >> The InstanceKlass has offsets to fields in the instance, and they
>>>>> depend
>>>>>  >> on both compressed oops and compressed klass pointers.   So both
>>>>> have to
>>>>>  >> be on for the offsets to be valid.
>>>>>  >>
>>>>>  >> But the base and compressed values are not stored anywhere in the
>>>>> CDS
>>>>>  >> archive.
>>>>>  >>
>>>>>  >>> And you don't care about UseCompressedOops and
>>>>>  >>> UseCompressedKlassPointers flags settings when you dump it into
>>>>>  >>> archive. The only limit is:
>>>>>  >>>
>>>>>  >>> Metaspace::class_metaspace_size() < (uint64_t)(max_juint) -
>>>>> cds_total
>>>>>  >>>
>>>>>  >>> Then I don't understand why you can't use/load CDS archive when
>>>>> coop
>>>>>  >>> or compklass are off:
>>>>>  >>>
>>>>>  >>> > If coop is turned off then CDS cannot be used.  CDS will 
>>>>> only be
>>>>>  >>> > supported if both UseCompressedOops and
>>>>> UseCompressedKlassPointers
>>>>>  >>> are
>>>>>  >>> > TRUE.
>>>>>  >>>
>>>>>  >>> Also based on code in arguments.cpp it is allowed to specify
>>>>>  >>> -XX:+UseCompressedOops -XX:-UseCompressedKlassPointers on
>>>>> command line:
>>>>>  >>>
>>>>>  >>> 1466     // Turn on UseCompressedKlassPointers too
>>>>>  >>> 1467     if (FLAG_IS_DEFAULT(UseCompressedKlassPointers)) {
>>>>>  >>> 1468       FLAG_SET_ERGO(bool, UseCompressedKlassPointers, 
>>>>> true);
>>>>>  >>> 1469     }
>>>>>  >>>
>>>>>  >>> Did you tested such combination?
>>>>>  >>
>>>>>  >> I should let Harold answer this but I believe this is what his 
>>>>> test
>>>>>  >> does.  For CDS on 64 bit, both must be on.   We didn't want to
>>>>> create 4
>>>>>  >> different archives.   And it wouldn't make too much sense since
>>>>> CDS for
>>>>>  >> 64 bit is a footprint savings so why would you use it without
>>>>>  >> compressing oops and class pointers?  It's not a startup 
>>>>> savings on
>>>>>  >> server because we turn off interpreter bytecode quickening.
>>>>>  >>
>>>>>  >> Coleen
>>>>>  >>
>>>>>  >>>
>>>>>  >>>>>
>>>>>  >>>>> set_narrow_klass_base_and_shift() and
>>>>>  >>>>> can_use_cds_with_metaspace_addr() have the same code for
>>>>>  >>>>> UseSharedSpaces. It would be nice to have only one copy. Call
>>>>>  >>>>> can_use_cds_with_metaspace_addr() from
>>>>>  >>>>> set_narrow_klass_base_and_shift() ?
>>>>>  >>>> I could add new inlined methods that determine the
>>>>> higher_address and
>>>>>  >>>> lower_base when UseSharedSpaces is true and have them called 
>>>>> from
>>>>>  >>>> set_narrow_klass_base_and_shift() and
>>>>>  >>>> can_use_cds_with_metaspace_addr(). Would that be worth doing?
>>>>>  >>>
>>>>>  >>> I tried several approaches but your implementation is more
>>>>> clean. So I
>>>>>  >>> agree to keep what you have now.
>>>>>  >>>
>>>>>  >>>
>>>>>  >>> Also I found strange assert which should always fail (old 
>>>>> code in
>>>>>  >>> global_initialize() in metaspace.cpp):
>>>>>  >>>
>>>>>  >>> 2959     if (UseSharedSpaces) {
>>>>>  >>> ...
>>>>>  >>> 2969       } else {
>>>>>  >>> 2970         assert(!mapinfo->is_open() && !UseSharedSpaces,
>>>>>  >>> 2971                "archive file not closed or shared spaces 
>>>>> not
>>>>>  >>> disabled.");
>>>>>  >>>
>>>>>  >>> Thanks,
>>>>>  >>> Vladimir
>>>>>  >>>
>>>>>  >>>>>
>>>>>  >>>>> I see that you unconditionally set comp klass ptr base and
>>>>> shift for
>>>>>  >>>>> DumpSharedSpaces. Should you do the check similar to
>>>>>  >>>>> can_use_cds_with_metaspace_addr() to find if you can do 
>>>>> that? You
>>>>>  >>>>> don't even check UseCompressedKlassPointers.
>>>>>  >>>> I don't think the checks are needed because the information
>>>>> written to
>>>>>  >>>> the archive is not affected by the size of the class metaspace.
>>>>>  >>>>
>>>>>  >>>> Also, I recently added code to arguments.cpp that will 
>>>>> generate an
>>>>>  >>>> error
>>>>>  >>>> if UseCompressedOops or UseCompressedKlassPointers is turned
>>>>> off and
>>>>>  >>>> DumpSharedSpaces is on.
>>>>>  >>>>>
>>>>>  >>>>> Why you have next limitation? What if coop can't be used
>>>>> because of
>>>>>  >>>>> big heap?:
>>>>>  >>>>>
>>>>>  >>>>> +     // UseCompressedOops and UseCompressedKlassPointers must
>>>>> be on
>>>>>  >>>>> for UseSharedSpaces.
>>>>>  >>>>> +     if (!UseCompressedOops || !UseCompressedKlassPointers) {
>>>>>  >>>>> +       no_shared_spaces();
>>>>>  >>>> If coop is turned off then CDS cannot be used.  CDS will 
>>>>> only be
>>>>>  >>>> supported if both UseCompressedOops and
>>>>> UseCompressedKlassPointers are
>>>>>  >>>> TRUE.
>>>>>  >>>>>
>>>>>  >>>>> Could you move UseCompressedKlassPointers code in
>>>>> arguments.cpp into
>>>>>  >>>>> separate method similar to set_use_compressed_oops()?
>>>>>  >>>> Done.
>>>>>  >>>>>
>>>>>  >>>>> About new tests.
>>>>>  >>>>> The first test in CDSCompressedKPtrsError misses
>>>>>  >>>>> -XX:+UseCompressedOops flag.
>>>>>  >>>> Fixed.
>>>>>  >>>>>
>>>>>  >>>>> Could you also test cross flags combinations?:
>>>>>  >>>>>
>>>>>  >>>>> -XX:-UseCompressedKlassPointers -XX:+UseCompressedOops
>>>>>  >>>>> -XX:+UseCompressedKlassPointers -XX:-UseCompressedOops
>>>>>  >>>> Done.
>>>>>  >>>>>
>>>>>  >>>>> It would be nice to have test to check ClassMetaspaceSize 
>>>>> value
>>>>>  >>>>> range.
>>>>>  >>>>> You have limited it to [1Mb, 3Gb]. BTW, why 3Gb? It is neither
>>>>> maxint
>>>>>  >>>>> or maxuint.
>>>>>  >>>> A member of our runtime SQE group is writing additional tests.
>>>>> I'll
>>>>>  >>>> ask
>>>>>  >>>> him to write a ClassMetaspaceSize range test.
>>>>>  >>>>
>>>>>  >>>> We chose 3Gb because we thought it was a sufficiently large 
>>>>> size.
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> About code style, indention. We align next line to
>>>>> corresponding part
>>>>>  >>>>> of previous line if we need to split a line. And sometimes 
>>>>> it is
>>>>>  >>>>> better to keep one long line. I understand some of them were
>>>>> before
>>>>>  >>>>> your changes but, please, clean up at lest ones you touched.
>>>>>  >>>> Done.
>>>>>  >>>>>
>>>>>  >>>>> Cases in metaspace.cpp:
>>>>>  >>>>>
>>>>>  >>>>> 2263   assert(raw_word_size >= min_size,
>>>>>  >>>>> 2264     err_msg("Should not deallocate dark matter "
>>>>> SIZE_FORMAT "<"
>>>>>  >>>>> SIZE_FORMAT, word_size, min_size));
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2485   if (Metaspace::using_class_space() &&
>>>>>  >>>>> 2486 (Metaspace::class_space_list() != NULL)) {
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2574   size_t reserved = (mdtype == Metaspace::ClassType) ?
>>>>>  >>>>> 2575 (Metaspace::using_class_space() ?
>>>>>  >>>>> 2576 Metaspace::class_space_list()->virtual_space_total() : 
>>>>> 0) :
>>>>>  >>>>> 2577 Metaspace::space_list()->virtual_space_total();
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2694   out->print_cr(" class: " SIZE_FORMAT " specialized(s) "
>>>>>  >>>>> SIZE_FORMAT ", "
>>>>>  >>>>> 2695 SIZE_FORMAT " small(s) " SIZE_FORMAT
>>>>>  >>>>> ", "
>>>>>  >>>>> 2696 SIZE_FORMAT " medium(s) " SIZE_FORMAT
>>>>>  >>>>> ", "
>>>>>  >>>>> 2697 "large count " SIZE_FORMAT,
>>>>>  >>>>> 2698 cls_specialized_count, cls_specialized_waste,
>>>>>  >>>>> 2699              cls_small_count, cls_small_waste,
>>>>>  >>>>> 2700              cls_medium_count, cls_medium_waste,
>>>>>  >>>>> cls_humongous_count);
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2872       while (!metaspace_rs.is_reserved() && (addr + 1*G >
>>>>>  >>>>> addr) &&
>>>>>  >>>>> 2873 can_use_cds_with_metaspace_addr(addr + 1*G, cds_base)) {
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 2889 vm_exit_during_initialization(err_msg(
>>>>>  >>>>> 2890           "Could not allocate metaspace: %d bytes",
>>>>>  >>>>> 2891 class_metaspace_size()));
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 3107     return using_class_space() ?
>>>>>  >>>>> 3108 class_vsm()->sum_used_in_chunks_in_use() : 0;
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 3157     if (is_class && using_class_space()) {
>>>>>  >>>>> 3158 class_vsm()->deallocate(ptr, word_size);
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> 3305   return space_list()->contains(ptr) ||
>>>>>  >>>>> 3306     (using_class_space() &&
>>>>> class_space_list()->contains(ptr));
>>>>>  >>>>>
>>>>>  >>>>> metaspace.hpp:
>>>>>  >>>>>
>>>>>  >>>>>  270     return
>>>>> _allocated_capacity_words[Metaspace::NonClassType] +
>>>>>  >>>>>  271 (Metaspace::using_class_space() ?
>>>>>  >>>>>  272 _allocated_capacity_words[Metaspace::ClassType] : 0);
>>>>>  >>>>>
>>>>>  >>>>>  285     return 
>>>>> _allocated_used_words[Metaspace::NonClassType] +
>>>>>  >>>>>  286 (Metaspace::using_class_space() ?
>>>>>  >>>>>  287 _allocated_used_words[Metaspace::ClassType] : 0);
>>>>>  >>>>>
>>>>>  >>>>> universe.cpp:
>>>>>  >>>>>
>>>>>  >>>>>  849 assert((intptr_t)Universe::narrow_oop_base() <=
>>>>>  >>>>> (intptr_t)(Universe::heap()->base() -
>>>>>  >>>>>  850     os::vm_page_size()) ||
>>>>>  >>>>>  851 Universe::narrow_oop_base() == NULL, "invalid
>>>>>  >>>>> value");
>>>>>  >>>>>
>>>>>  >>>>>
>>>>>  >>>>> Thanks,
>>>>>  >>>>> Vladimir
>>>>>  >>>>>
>>>>>  >>>>> On 8/2/13 1:31 PM, harold seigel wrote:
>>>>>  >>>>>> Hi,
>>>>>  >>>>>>
>>>>>  >>>>>> Please review this updated webrev for bug 8003424:
>>>>>  >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424.2/
>>>>>  >>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424.2/>
>>>>>  >>>>>>
>>>>>  >>>>>> The updated webrev has a lot of changes from the previous
>>>>> webrev,
>>>>>  >>>>>> including the following:
>>>>>  >>>>>>
>>>>>  >>>>>>     1. Class metaspace information is now output when
>>>>>  >>>>>>     -XX:+PrintCompressedOopsMode is specified.
>>>>>  >>>>>>
>>>>>  >>>>>>     2. decode_klass_not_null(Register dst, Register src) no
>>>>> longer
>>>>>  >>>>>>     clobbers R12.
>>>>>  >>>>>>
>>>>>  >>>>>>     3. Method using_class_vsm() was renamed to
>>>>> using_class_space().
>>>>>  >>>>>>
>>>>>  >>>>>>     4. Type narrowKlass was added and replaces narrowOop, 
>>>>> where
>>>>>  >>>>>> appropriate.
>>>>>  >>>>>>
>>>>>  >>>>>>     5. The Metaspace:: qualifier was removed, where it was
>>>>>  >>>>>> unnecessary.
>>>>>  >>>>>>
>>>>>  >>>>>>     6. Metaspace::initialize_class_space() was made private.
>>>>>  >>>>>>
>>>>>  >>>>>>     7. Method max_heap_for_compressed_oops(), in
>>>>> arguments.cpp, was
>>>>>  >>>>>> updated.
>>>>>  >>>>>>
>>>>>  >>>>>> Performance tests were run by Jenny using specjvm2008,
>>>>> specjbb2005,
>>>>>  >>>>>> and
>>>>>  >>>>>> specjbb2013.  The results showed no significant performance
>>>>>  >>>>>> difference
>>>>>  >>>>>> in terms of scores and gc behavior.
>>>>>  >>>>>>
>>>>>  >>>>>> Additional testing was done on Solaris Sparc and Linux x86 
>>>>> using
>>>>>  >>>>>> SpecJBB2005 with -Xmx34g and -XX:ObjectAlignmentInBytes=16 
>>>>> & 32.
>>>>>  >>>>>>
>>>>>  >>>>>> Please let me know what additional tests should be run.
>>>>>  >>>>>>
>>>>>  >>>>>> Thanks!
>>>>>  >>>>>> Harold
>>>>>  >>>>>>
>>>>>  >>>>>> On 7/24/2013 4:36 PM, Vladimir Kozlov wrote:
>>>>>  >>>>>>> Hi Harold,
>>>>>  >>>>>>>
>>>>>  >>>>>>> > Usually the narrow_klass_base will be 32G and the
>>>>>  >>>>>>> > LogKlassAlignmentInBytes will be 3 (8 bytes alignment) 
>>>>> which
>>>>>  >>>>>>> means
>>>>>  >>>>>>> that
>>>>>  >>>>>>> > narrow_klass_base >> 3 will exceed maxint. So, we will
>>>>> need R12,
>>>>>  >>>>>>> unless
>>>>>  >>>>>>> > we do multiple addq(r, narrow_klass_base_shifted()). Does
>>>>> that
>>>>>  >>>>>>> make
>>>>>  >>>>>>> sense?
>>>>>  >>>>>>>
>>>>>  >>>>>>> My bad, I miscalculated. But we have "perfect value"
>>>>> 0x800000000
>>>>>  >>>>>>> and I
>>>>>  >>>>>>> am tempted to use may be bts (bit set) to avoid R12 usage
>>>>>  >>>>>>> (assuming or
>>>>>  >>>>>>> with check that class metaspace size < 32Gb).
>>>>>  >>>>>>>
>>>>>  >>>>>>> > Is there one prefix byte per instruction, or just for 
>>>>> certain
>>>>>  >>>>>>> instructions?
>>>>>  >>>>>>>
>>>>>  >>>>>>> "Not all instructions require a REX prefix in 64-bit mode. A
>>>>>  >>>>>>> prefix is
>>>>>  >>>>>>> necessary only if an instruction references one of the 
>>>>> extended
>>>>>  >>>>>>> registers or uses a 64-bit operand."
>>>>>  >>>>>>>
>>>>>  >>>>>>> I want you also run tests with -XX:ObjectAlignmentInBytes=16
>>>>> and
>>>>>  >>>>>>> =32
>>>>>  >>>>>>> and big java heap. Recently we got several bugs which 
>>>>> indicated
>>>>>  >>>>>>> that
>>>>>  >>>>>>> we did not separate cleanly oops and klass pointers
>>>>> en/decoding.
>>>>>  >>>>>>>
>>>>>  >>>>>>> Thanks,
>>>>>  >>>>>>> Vladimir
>>>>>  >>>>>>>
>>>>>  >>>>>>> On 7/24/13 11:35 AM, harold seigel wrote:
>>>>>  >>>>>>>> Hi Vladimir,
>>>>>  >>>>>>>>
>>>>>  >>>>>>>> Thank you for the review! Please see inline comments.
>>>>>  >>>>>>>>
>>>>>  >>>>>>>> Thanks, Harold
>>>>>  >>>>>>>>
>>>>>  >>>>>>>> On 7/19/2013 7:56 PM, Vladimir Kozlov wrote:
>>>>>  >>>>>>>>> On 7/18/13 3:03 PM, Vladimir Kozlov wrote:
>>>>>  >>>>>>>>>> Nice clean up, Harold
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> Could you add the size of class metaspace in output with
>>>>>  >>>>>>>>>> PrintCompressedOopsMode (and with verbose). I don't 
>>>>> want to
>>>>>  >>>>>>>>>> remember an
>>>>>  >>>>>>>>>> other very long flag name: 
>>>>> TraceMetavirtualspaceAllocation.
>>>>>  >>>>>>>> Will be done in next webrev.
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> Also it would be nice to print these info line (and
>>>>> compressed
>>>>>  >>>>>>>>>> oops
>>>>>  >>>>>>>>>> info
>>>>>  >>>>>>>>>> line) in hs_err files.
>>>>>  >>>>>>>> I filed an enhancement bug for this: 8021264
>>>>>  >>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021264>.
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> About "effect(KILL cr);   /// ???? is this KILL 
>>>>> needed?" in
>>>>>  >>>>>>>>>> x86_64.ad.
>>>>>  >>>>>>>>>> encode_klass_not_null() and decode_klass_not_null() use
>>>>>  >>>>>>>>>> arithmetic
>>>>>  >>>>>>>>>> instructions which modify flags: subq, addq, shrq,
>>>>> xorptr. Also
>>>>>  >>>>>>>>>> note
>>>>>  >>>>>>>>>> that code in .ad file does not check the encoding mode 
>>>>> for
>>>>>  >>>>>>>>>> narrow
>>>>>  >>>>>>>>>> klass/oop so it should be conservative and assume that
>>>>>  >>>>>>>>>> arithmetic
>>>>>  >>>>>>>>>> instructions are used.
>>>>>  >>>>>>>> OK. Thanks.
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> If Universe::narrow_klass_shift() == 0 you have klass
>>>>> base below
>>>>>  >>>>>>>>>> 4Gb so
>>>>>  >>>>>>>>>> the value is 32 bit. You can use it directly in narrow 
>>>>> klass
>>>>>  >>>>>>>>>> encoding/decoding without destroying R12.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> Correction. You can do it only if base < 2Gb max 
>>>>> positive int
>>>>>  >>>>>>>>> (sign
>>>>>  >>>>>>>>> bit is extended so you will get wrong result with address
>>>>> > 2gb).
>>>>>  >>>>>>>> But the base will normally be 32Gb.  So this case won't 
>>>>> happen
>>>>>  >>>>>>>> very
>>>>>  >>>>>>>> often.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> You definitely should not use R12 in
>>>>>  >>>>>>>>> decode_klass_not_null(Register
>>>>>  >>>>>>>>> dst, Register src) method where you have free 'dst' 
>>>>> register.
>>>>>  >>>>>>>> Will be fixed in next webrev.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> About CompressedKlassPointersBase 0x800000000 (32*G).
>>>>> Actually it
>>>>>  >>>>>>>>> should depend on ObjectAlignmentInBytes. For =16 it 
>>>>> should be
>>>>>  >>>>>>>>> 64Gb.
>>>>>  >>>>>>>>> The idea was to avoid using R12 by using shifted base:
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> decode:
>>>>>  >>>>>>>>> if (Universe::narrow_klass_base_shifted() != 0) {
>>>>>  >>>>>>>>>   if (Universe::set_narrow_klass_shift() == 0) {
>>>>>  >>>>>>>>>     shrq(r, LogKlassAlignmentInBytes);
>>>>>  >>>>>>>>>   }
>>>>>  >>>>>>>>>   addq(r, Universe::narrow_klass_base_shifted());
>>>>>  >>>>>>>>>   shlq(r, LogKlassAlignmentInBytes);
>>>>>  >>>>>>>>> }
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> Universe::narrow_klass_base_shifted() is set only if
>>>>>  >>>>>>>>> (Universe::narrow_klass_base >> 
>>>>> LogKlassAlignmentInBytes) <=
>>>>>  >>>>>>>>> maxint
>>>>>  >>>>>>>>> (max positive int).
>>>>>  >>>>>>>> Usually the narrow_klass_base will be 32G and the
>>>>>  >>>>>>>> LogKlassAlignmentInBytes will be 3 (8 bytes alignment)
>>>>> which means
>>>>>  >>>>>>>> that
>>>>>  >>>>>>>> narrow_klass_base >> 3 will exceed maxint. So, we will need
>>>>> R12,
>>>>>  >>>>>>>> unless
>>>>>  >>>>>>>> we do multiple addq(r, narrow_klass_base_shifted()). 
>>>>> Does that
>>>>>  >>>>>>>> make
>>>>>  >>>>>>>> sense?
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> And you have general memory reservation problem. At 
>>>>> least on
>>>>>  >>>>>>>>> Solaris,
>>>>>  >>>>>>>>> as I remember, OS will always try to keep protected 4Kb 
>>>>> pages
>>>>>  >>>>>>>>> between
>>>>>  >>>>>>>>> different requested memory regions. That is why in jdk7 we
>>>>> first
>>>>>  >>>>>>>>> reserve one huge space and then cut it on java heap, perm
>>>>> gen and
>>>>>  >>>>>>>>> protection page below heap to catch implicit NULL
>>>>> exceptions with
>>>>>  >>>>>>>>> compressed oops.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> So, please, verify that you are getting 'cds_address +
>>>>> cds_total'
>>>>>  >>>>>>>>> address or CompressedKlassPointersBase without CDS and 
>>>>> with
>>>>>  >>>>>>>>> compressed
>>>>>  >>>>>>>>> oops and with Xmx20Gb.
>>>>>  >>>>>>>> I verifed that we get either cds_address+cds_total as the
>>>>>  >>>>>>>> address, or
>>>>>  >>>>>>>> CompressedKlassPointersBase as the address without CDS on
>>>>> Linux,
>>>>>  >>>>>>>> Windows
>>>>>  >>>>>>>> 7, Mac OS, and Solaris 5.11. This is true with default heap
>>>>>  >>>>>>>> sizes and
>>>>>  >>>>>>>> -Xmx32G.
>>>>>  >>>>>>>>
>>>>>  >>>>>>>> On Solaris 5.10, I don't get CompressedKlassPointersBase or
>>>>> the
>>>>>  >>>>>>>> desired
>>>>>  >>>>>>>> CDS address for class metaspace regardless of heap size.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> instr_size_for_decode_klass_not_null() is ugly but
>>>>>  >>>>>>>>>> unfortunately we
>>>>>  >>>>>>>>>> can't do other way. I assume you use max size because
>>>>>  >>>>>>>>>> depending on
>>>>>  >>>>>>>>>> registers used in instructions you will or will not get
>>>>> prefix
>>>>>  >>>>>>>>>> byte
>>>>>  >>>>>>>>>> (r8-r15).
>>>>>  >>>>>>>> Is there one prefix byte per instruction, or just for 
>>>>> certain
>>>>>  >>>>>>>> instructions?
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> I will look on changes in more details may be late.
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>> What 'vsm' stands for in using_class_vsm()? Don't use
>>>>>  >>>>>>>>> abbreviations
>>>>>  >>>>>>>>> which are not obvious.
>>>>>  >>>>>>>> I changed using_class_vsm() to using_class_space().
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>>
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> Thanks,
>>>>>  >>>>>>>>>> Vladimir
>>>>>  >>>>>>>>>>
>>>>>  >>>>>>>>>> On 7/18/13 10:54 AM, harold seigel wrote:
>>>>>  >>>>>>>>>>> Hi,
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Please review this fix for bug 8003424.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Open webrev at
>>>>> http://cr.openjdk.java.net/~hseigel/bug_8003424/
>>>>>  >>>>>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8003424/>
>>>>>  >>>>>>>>>>> Open bug links at:
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8003424
>>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016729
>>>>>  >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011610
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> JBS Bug links at
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8003424
>>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8016729
>>>>>  >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8011610
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> This fix provides support for using compressed klass
>>>>> pointers
>>>>>  >>>>>>>>>>> with
>>>>>  >>>>>>>>>>> CDS.
>>>>>  >>>>>>>>>>> It also changes the class metaspace allocation on 64-bit
>>>>>  >>>>>>>>>>> platforms
>>>>>  >>>>>>>>>>> when
>>>>>  >>>>>>>>>>> UseCompressedKlassPointers is true.  Instead of
>>>>> allocating the
>>>>>  >>>>>>>>>>> class
>>>>>  >>>>>>>>>>> metaspace as part of the Java Heap allocation and 
>>>>> locating
>>>>>  >>>>>>>>>>> it at
>>>>>  >>>>>>>>>>> the
>>>>>  >>>>>>>>>>> base of that allocation, the metaspace will now be
>>>>> allocated
>>>>>  >>>>>>>>>>> separately,
>>>>>  >>>>>>>>>>> above the Java heap.  This will enable future expansion
>>>>> of the
>>>>>  >>>>>>>>>>> metaspace
>>>>>  >>>>>>>>>>> because it won't be backed up against the Java heap. If
>>>>> CDS is
>>>>>  >>>>>>>>>>> being
>>>>>  >>>>>>>>>>> used, then the CDS region will be allocated between the
>>>>> Java
>>>>>  >>>>>>>>>>> heap and
>>>>>  >>>>>>>>>>> the metaspace.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> The new class metaspace allocation code tries to 
>>>>> allocate
>>>>>  >>>>>>>>>>> memory at
>>>>>  >>>>>>>>>>> 32G,
>>>>>  >>>>>>>>>>> or above the CDS region, if it is present. Because of 
>>>>> this,
>>>>>  >>>>>>>>>>> encoding
>>>>>  >>>>>>>>>>> and decoding of compressed klass pointers will always
>>>>>  >>>>>>>>>>> require use
>>>>>  >>>>>>>>>>> of a
>>>>>  >>>>>>>>>>> base register. So, encoding and decoding of compressed
>>>>> klass
>>>>>  >>>>>>>>>>> pointers
>>>>>  >>>>>>>>>>> will differ from compressed oops.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> There are no class metaspace allocation changes if
>>>>>  >>>>>>>>>>> UseCompressedKlassPointers is turned off or if 
>>>>> running on a
>>>>>  >>>>>>>>>>> 32-bit
>>>>>  >>>>>>>>>>> platform.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> The code changes also include some cleanup and will fix
>>>>> bugs
>>>>>  >>>>>>>>>>> 8016729,
>>>>>  >>>>>>>>>>> 8011610, and 8003424.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Many of the modules in this webrev contain a lot of
>>>>> changes.
>>>>>  >>>>>>>>>>> Modules
>>>>>  >>>>>>>>>>> macroAssembler_sparc.cpp and macroAssembler_x86.cpp were
>>>>>  >>>>>>>>>>> changed to
>>>>>  >>>>>>>>>>> support the new encoding and decoding of compressed 
>>>>> klass
>>>>>  >>>>>>>>>>> pointers.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Module metaspace.cpp was changed significantly to 
>>>>> support
>>>>>  >>>>>>>>>>> the new
>>>>>  >>>>>>>>>>> allocation for metaspace and the CDS region and to
>>>>> determine
>>>>>  >>>>>>>>>>> compressed
>>>>>  >>>>>>>>>>> klass pointer encoding base and shifting values.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Most of the changes to module universe.cpp were to
>>>>> remove code
>>>>>  >>>>>>>>>>> related
>>>>>  >>>>>>>>>>> to allocating metaspace and remove code that considered
>>>>>  >>>>>>>>>>> compressed
>>>>>  >>>>>>>>>>> klass
>>>>>  >>>>>>>>>>> pointers when determining the compressed oops 
>>>>> compression
>>>>>  >>>>>>>>>>> mechanism.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Modules klass.inline.hpp and oop.inline.hpp were 
>>>>> changed as
>>>>>  >>>>>>>>>>> part
>>>>>  >>>>>>>>>>> of a
>>>>>  >>>>>>>>>>> cleanup requested by Coleen.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> These changes were tested with JCK Lang and VM tests, 
>>>>> JTReg
>>>>>  >>>>>>>>>>> tests,
>>>>>  >>>>>>>>>>> JPRT,
>>>>>  >>>>>>>>>>> GCBasher, refworkload, ute vm.quick.testlist and
>>>>>  >>>>>>>>>>> vm.mlvm.testlist
>>>>>  >>>>>>>>>>> tests.  Most of the test were run with -Xshare:on and
>>>>>  >>>>>>>>>>> -Xshare:off
>>>>>  >>>>>>>>>>> (with
>>>>>  >>>>>>>>>>> and without CDS), and were run on Solaris Sparc, 32-Bit
>>>>>  >>>>>>>>>>> Linux and
>>>>>  >>>>>>>>>>> 64-Bit
>>>>>  >>>>>>>>>>> Linux. Jtreg tests were run on Windows 7 and Mac OS.
>>>>> JCK tests
>>>>>  >>>>>>>>>>> were
>>>>>  >>>>>>>>>>> run on Solaris x86.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> The performance impact of these changes is TBD.
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>> Thanks, Harold
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>>>>
>>>>>  >>>>>>>>
>>>>>  >>>>>>
>>>>>  >>>>
>>>>>  >>
>>>>>
>>>
>


From harold.seigel at oracle.com  Thu Aug 15 19:29:10 2013
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Fri, 16 Aug 2013 02:29:10 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8003424: Enable Class Data Sharing for
	CompressedOops; ...
Message-ID: <20130816022913.451264891D@hg.openjdk.java.net>

Changeset: 740e263c80c6
Author:    hseigel
Date:      2013-08-15 20:04 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/740e263c80c6

8003424: Enable Class Data Sharing for CompressedOops
8016729: ObjectAlignmentInBytes=16 now forces the use of heap based compressed oops
8005933: The -Xshare:auto option is ignored for -server
Summary: Move klass metaspace above the heap and support CDS with compressed klass ptrs.
Reviewed-by: coleenp, kvn, mgerdin, tschatzl, stefank

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/relocInfo_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klass.inline.hpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/utilities/globalDefinitions.hpp
+ test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java
+ test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java
+ test/runtime/CDSCompressedKPtrs/XShareAuto.java
! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java


From christian.thalinger at oracle.com  Thu Aug 15 19:38:43 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 15 Aug 2013 19:38:43 -0700
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
Message-ID: <A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>


On Aug 15, 2013, at 9:05 AM, David Chase <david.r.chase at oracle.com> wrote:

> Webrev: http://cr.openjdk.java.net/~drchase/8014013/webrev.01/

src/share/vm/interpreter/linkResolver.cpp (and others):

+   debug_only(verify());  // verify before making side effects

Use upper-case DEBUG_ONLY.  debug_only is deprecated.

+   if (resolved_klass == NULL)  // 2nd argument defaults to holder of 1st
+     resolved_klass = resolved_method_holder;
+   _resolved_klass  = resolved_klass;
+   _selected_klass  = resolved_klass;
+   _resolved_method = resolved_method;
+   _selected_method = resolved_method;

It is almost impossible to see that there is an if statement and where it ends.  Add {}.

+     ShouldNotReachHere();  // C++ constructor failure

fatal with error message would be better.

src/share/vm/oops/method.cpp:

+ // These are methods do not need vtable entries.
+ bool Method::is_final_method(AccessFlags class_access_flags) const {

This comment reads odd.

src/share/vm/opto/library_call.cpp:

+   assert(vtable_index >= 0 || vtable_index == Method::nonvirtual_vtable_index, err_msg("bad index %d", vtable_index));

Please use err_msg_res in the compiler.  We had problems with stack overflows in the past.

src/share/vm/runtime/fieldDescriptor.cpp:

+   if (_cp.is_null() || field_holder() != ik) {
+     _cp = constantPoolHandle(Thread::current(), ik->constants());
+     assert(field_holder() == ik, "must be already initialized to this class");
+   }

This assert cannot hold.

-- Chris

> 
> Bug: The addition of interface (default) methods made the old way
> of resolving method invocation not be right. 
> In addition, the code was fiddly and distributed through the source.
> See also duplicate 7086758,
> "MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited"
> 
> Fix: Enhance method resolution (add "CallKind")
> and the data structures for reporting resolution results,
> and centralize the process as much as possible.
> 
> Testing:
> 
> Note: this fix is bug-for-bug-compatible with current on jdk/lambda/vm/DefaultMethodsTest.java 
> 
> 64-bit Intel (MacOS):
> jtreg - compiler
> jtreg - jdk/{lib,sun,java/util, java/lang, jdk}
> ute/tonga - vm.quick.testlist
> 
> 32-bit Intel (Ubuntu)
> Point checks on all the corner cases from the 64-bit testing.
> (jck60008, b7087658)
> jtreg - jdk/{java/util, java/lang, jdk}
> 
> Solaris-sparc
> jtreg - jdk/{java/util, java/lang, jdk}
> 
> Also compiled on Windows/VS2010 w/ JPRT.
> 
> 


From david.r.chase at oracle.com  Thu Aug 15 19:50:45 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 15 Aug 2013 22:50:45 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
Message-ID: <6C2E3F57-9C21-4191-8B4E-8DA754F7638B@oracle.com>

Thanks much, I will attend to these tomorrow.
David

On 2013-08-15, at 10:38 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
...


From john.r.rose at oracle.com  Thu Aug 15 23:12:36 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 15 Aug 2013 23:12:36 -0700
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
Message-ID: <6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>

On Aug 15, 2013, at 7:38 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> src/share/vm/runtime/fieldDescriptor.cpp:
> 
> +   if (_cp.is_null() || field_holder() != ik) {
> +     _cp = constantPoolHandle(Thread::current(), ik->constants());
> +     assert(field_holder() == ik, "must be already initialized to this class");
> +   }
> 
> This assert cannot hold.

The fd::initialize call resets a fd previously pointing at a different field to a new field.
This requires a shift in the field_holder.
The call to initialize is fieldStreams.hpp, where a fd embedded in the stream object gets reused for successive fields.
So I think this assert measures something meaningful.
Perhaps the method should be named "reinitialize" or "reset" to emphasize the multiple use.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130815/04fc38f9/attachment.html 

From david.holmes at oracle.com  Thu Aug 15 23:25:39 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 16 Aug 2013 16:25:39 +1000
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
Message-ID: <520DC5E3.6020302@oracle.com>

On 16/08/2013 4:12 PM, John Rose wrote:
> On Aug 15, 2013, at 7:38 PM, Christian Thalinger
> <christian.thalinger at oracle.com <mailto:christian.thalinger at oracle.com>>
> wrote:
>
>> src/share/vm/runtime/fieldDescriptor.cpp:
>>
>> +   if (_cp.is <http://cp.is/>_null() || field_holder() != ik) {
>> +     _cp = constantPoolHandle(Thread::current(), ik->constants());
>> +     assert(field_holder() == ik, "must be already initialized to
>> this class");
>> +   }
>>
>> This assert cannot hold.
>
> The fd::initialize call resets a fd previously pointing at a different
> field to a new field.
> This requires a shift in the field_holder.
> The call to initialize is fieldStreams.hpp, where a fd embedded in the
> stream object gets reused for successive fields.
> So I think this assert measures something meaningful.

But the second part of the if condition is "field_holder() != ik" - so 
how does the call to constantPoolHandle force field_holder() to a value 
that isn't even passed to it ???

David
-----

> Perhaps the method should be named "reinitialize" or "reset" to
> emphasize the multiple use.
>
> ? John

From john.r.rose at oracle.com  Fri Aug 16 00:39:00 2013
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 16 Aug 2013 00:39:00 -0700
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <520DC5E3.6020302@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<520DC5E3.6020302@oracle.com>
Message-ID: <88D78D15-F3D5-417E-A628-E639186DA418@oracle.com>

On Aug 15, 2013, at 11:25 PM, David Holmes <david.holmes at oracle.com> wrote:

> But the second part of the if condition is "field_holder() != ik" - so how does the call to constantPoolHandle force field_holder() to a value that isn't even passed to it ???

That part needs a comment.  Check the definition of field_holder.  ? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/e480e0ba/attachment-0001.html 

From erik.helin at oracle.com  Fri Aug 16 03:22:08 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 16 Aug 2013 12:22:08 +0200
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <520CDD99.70403@oracle.com>
References: <20130814144906.GC2649@ehelin-thinkpad> <520CDD99.70403@oracle.com>
Message-ID: <20130816102208.GA2238@ehelin-thinkpad>

On 2013-08-15, Mikael Gerdin wrote:
> Erik,
> 
> On 08/14/2013 04:49 PM, Erik Helin wrote:
> >Hi all,
> >
> >this change adds performance counters for compressed class space.
> >
> >Webrev:
> >http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
> >
> >Changes to hotspot:
> >The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
> >where the class MetaspaceCounters has been split up into
> >MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
> >an instance of MetaspacePerfCounters. The class
> >CompressedClassSpaceCounters has been added which also has its own
> >instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
> >updates the actual performance counters.
> 
> I'm a bit concerned about the exception handling in the perf
> variable creation. But it appears to be similar to the other places
> where perf variables are created.
> 
> Creating a 0-reporting perf counter if -UseCompressedKlassPointers
> seems consistent with the rest of the code.
> 
> I'd say this is fine, but as Coleen mentioned you should verify this
> with Harold's change for CDS+CompressedOops.

Coleen, Mikael,

I've rebased the change on top of hotspot-rt (which includes Harold's
change). I had to resolve some merge conflicts in metaspace.cpp.

Please see the latest (and hopefully final) webrev at:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.04/

The incremental changes since the first webrev are listed below:
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.03-04/
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.02-03/
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/

I plan to push this to hotspot-rt as well, since the change now depends
on Harold's change.

Thanks,
Erik

> >The changes in metaspace.hpp/cpp were needed to get some additional data
> >from the metaspace data structures. The method
> >free_chunks_in_total(mdtype) was made public and the method
> >free_bytes(mdtype) was added. Some common functionality was extracted
> >into get_space_list(mdtype) which got rid of some duplicated code.
> >
> >The changes in:
> >- g1MonitorinSupport.cpp
> >- parallelScavengeHeap.cpp
> >- genCollectedHeap.cpp
> >- universe.cpp
> >are only "one-liners" that either update or initialize the new performance
> >counters.
> >
> >Changes to the testlibrary:
> >- Added Asserts.java for writing asserts like "assertTrue",
> >   "assertEquals", etc.
> >- Added PerfCounter.java and PerfCounters.java to make it easy to
> >   inspect performance counters for the currently running VM.
> >- Added InputArguments.java so a test can check the arguments it got
> >   passed.
> >- Added InMemoryJavaCompiler.java for compiling a string into bytecode.
> >   Useful for loading classes generated at runtime without using files.
> >- Added ByteCodeLoader.java for defining a new class when you already
> >   have the bytecode.
> 
> The test code looks fine.
> 
> /Mikael
> >
> >Testing:
> >- Added the new test TestMetaspacePerfCounters.java
> >- JPRT
> >
> >Bug:
> >http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
> >
> >Thanks,
> >Erik
> >
> 

From mikael.gerdin at oracle.com  Fri Aug 16 05:07:20 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 16 Aug 2013 14:07:20 +0200
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <20130816102208.GA2238@ehelin-thinkpad>
References: <20130814144906.GC2649@ehelin-thinkpad> <520CDD99.70403@oracle.com>
	<20130816102208.GA2238@ehelin-thinkpad>
Message-ID: <520E15F8.7050004@oracle.com>

Erik,

On 2013-08-16 12:22, Erik Helin wrote:
> On 2013-08-15, Mikael Gerdin wrote:
>> Erik,
>>
>> On 08/14/2013 04:49 PM, Erik Helin wrote:
>>> Hi all,
>>>
>>> this change adds performance counters for compressed class space.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
>>>
>>> Changes to hotspot:
>>> The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
>>> where the class MetaspaceCounters has been split up into
>>> MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
>>> an instance of MetaspacePerfCounters. The class
>>> CompressedClassSpaceCounters has been added which also has its own
>>> instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
>>> updates the actual performance counters.
>>
>> I'm a bit concerned about the exception handling in the perf
>> variable creation. But it appears to be similar to the other places
>> where perf variables are created.
>>
>> Creating a 0-reporting perf counter if -UseCompressedKlassPointers
>> seems consistent with the rest of the code.
>>
>> I'd say this is fine, but as Coleen mentioned you should verify this
>> with Harold's change for CDS+CompressedOops.
>
> Coleen, Mikael,
>
> I've rebased the change on top of hotspot-rt (which includes Harold's
> change). I had to resolve some merge conflicts in metaspace.cpp.
>
> Please see the latest (and hopefully final) webrev at:
> http://cr.openjdk.java.net/~ehelin/8014659/webrev.04/

Still looks good to me.

/Mikael

>
> The incremental changes since the first webrev are listed below:
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.03-04/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.02-03/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/
>
> I plan to push this to hotspot-rt as well, since the change now depends
> on Harold's change.
>
> Thanks,
> Erik
>
>>> The changes in metaspace.hpp/cpp were needed to get some additional data
>> >from the metaspace data structures. The method
>>> free_chunks_in_total(mdtype) was made public and the method
>>> free_bytes(mdtype) was added. Some common functionality was extracted
>>> into get_space_list(mdtype) which got rid of some duplicated code.
>>>
>>> The changes in:
>>> - g1MonitorinSupport.cpp
>>> - parallelScavengeHeap.cpp
>>> - genCollectedHeap.cpp
>>> - universe.cpp
>>> are only "one-liners" that either update or initialize the new performance
>>> counters.
>>>
>>> Changes to the testlibrary:
>>> - Added Asserts.java for writing asserts like "assertTrue",
>>>    "assertEquals", etc.
>>> - Added PerfCounter.java and PerfCounters.java to make it easy to
>>>    inspect performance counters for the currently running VM.
>>> - Added InputArguments.java so a test can check the arguments it got
>>>    passed.
>>> - Added InMemoryJavaCompiler.java for compiling a string into bytecode.
>>>    Useful for loading classes generated at runtime without using files.
>>> - Added ByteCodeLoader.java for defining a new class when you already
>>>    have the bytecode.
>>
>> The test code looks fine.
>>
>> /Mikael
>>>
>>> Testing:
>>> - Added the new test TestMetaspacePerfCounters.java
>>> - JPRT
>>>
>>> Bug:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
>>>
>>> Thanks,
>>> Erik
>>>
>>

From harold.seigel at oracle.com  Fri Aug 16 05:10:33 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 16 Aug 2013 08:10:33 -0400
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <20130816102208.GA2238@ehelin-thinkpad>
References: <20130814144906.GC2649@ehelin-thinkpad> <520CDD99.70403@oracle.com>
	<20130816102208.GA2238@ehelin-thinkpad>
Message-ID: <520E16B9.4000406@oracle.com>

Hi Erik,

Thanks for doing the work of merging our two changes.  I had one small 
comment.  In MetaspaceAux::reserved_in_bytes() could you change this

    size_t reserved = list == NULL ? 0 : list->virtual_space_total();
    return reserved;

to

    return list == NULL ? 0 : list->virtual_space_total();

Thanks, Harold


On 8/16/2013 6:22 AM, Erik Helin wrote:
> On 2013-08-15, Mikael Gerdin wrote:
>> Erik,
>>
>> On 08/14/2013 04:49 PM, Erik Helin wrote:
>>> Hi all,
>>>
>>> this change adds performance counters for compressed class space.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
>>>
>>> Changes to hotspot:
>>> The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
>>> where the class MetaspaceCounters has been split up into
>>> MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
>>> an instance of MetaspacePerfCounters. The class
>>> CompressedClassSpaceCounters has been added which also has its own
>>> instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
>>> updates the actual performance counters.
>> I'm a bit concerned about the exception handling in the perf
>> variable creation. But it appears to be similar to the other places
>> where perf variables are created.
>>
>> Creating a 0-reporting perf counter if -UseCompressedKlassPointers
>> seems consistent with the rest of the code.
>>
>> I'd say this is fine, but as Coleen mentioned you should verify this
>> with Harold's change for CDS+CompressedOops.
> Coleen, Mikael,
>
> I've rebased the change on top of hotspot-rt (which includes Harold's
> change). I had to resolve some merge conflicts in metaspace.cpp.
>
> Please see the latest (and hopefully final) webrev at:
> http://cr.openjdk.java.net/~ehelin/8014659/webrev.04/
>
> The incremental changes since the first webrev are listed below:
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.03-04/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.02-03/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/
>
> I plan to push this to hotspot-rt as well, since the change now depends
> on Harold's change.
>
> Thanks,
> Erik
>
>>> The changes in metaspace.hpp/cpp were needed to get some additional data
>> >from the metaspace data structures. The method
>>> free_chunks_in_total(mdtype) was made public and the method
>>> free_bytes(mdtype) was added. Some common functionality was extracted
>>> into get_space_list(mdtype) which got rid of some duplicated code.
>>>
>>> The changes in:
>>> - g1MonitorinSupport.cpp
>>> - parallelScavengeHeap.cpp
>>> - genCollectedHeap.cpp
>>> - universe.cpp
>>> are only "one-liners" that either update or initialize the new performance
>>> counters.
>>>
>>> Changes to the testlibrary:
>>> - Added Asserts.java for writing asserts like "assertTrue",
>>>    "assertEquals", etc.
>>> - Added PerfCounter.java and PerfCounters.java to make it easy to
>>>    inspect performance counters for the currently running VM.
>>> - Added InputArguments.java so a test can check the arguments it got
>>>    passed.
>>> - Added InMemoryJavaCompiler.java for compiling a string into bytecode.
>>>    Useful for loading classes generated at runtime without using files.
>>> - Added ByteCodeLoader.java for defining a new class when you already
>>>    have the bytecode.
>> The test code looks fine.
>>
>> /Mikael
>>> Testing:
>>> - Added the new test TestMetaspacePerfCounters.java
>>> - JPRT
>>>
>>> Bug:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
>>>
>>> Thanks,
>>> Erik
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/b49390f8/attachment.html 

From erik.helin at oracle.com  Fri Aug 16 06:25:55 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 16 Aug 2013 15:25:55 +0200
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <520E16B9.4000406@oracle.com>
References: <20130814144906.GC2649@ehelin-thinkpad> <520CDD99.70403@oracle.com>
	<20130816102208.GA2238@ehelin-thinkpad>
	<520E16B9.4000406@oracle.com>
Message-ID: <20130816132555.GA2135@ehelin-thinkpad>

On 2013-08-16, harold seigel wrote:
> Hi Erik,
> 
> Thanks for doing the work of merging our two changes.  I had one
> small comment.  In MetaspaceAux::reserved_in_bytes() could you
> change this
> 
>    size_t reserved = list == NULL ? 0 : list->virtual_space_total();
>    return reserved;
> 
> to
> 
>    return list == NULL ? 0 : list->virtual_space_total();

Nice catch, thanks! I've uploaded a new webrev to:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.05/

The incremental changes since the first webrev are list below:
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.04-05/
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.03-04/
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.02-03/
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/
- http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/

Thanks,
Erik

> Thanks, Harold
> 
> 
> On 8/16/2013 6:22 AM, Erik Helin wrote:
> >On 2013-08-15, Mikael Gerdin wrote:
> >>Erik,
> >>
> >>On 08/14/2013 04:49 PM, Erik Helin wrote:
> >>>Hi all,
> >>>
> >>>this change adds performance counters for compressed class space.
> >>>
> >>>Webrev:
> >>>http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
> >>>
> >>>Changes to hotspot:
> >>>The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
> >>>where the class MetaspaceCounters has been split up into
> >>>MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
> >>>an instance of MetaspacePerfCounters. The class
> >>>CompressedClassSpaceCounters has been added which also has its own
> >>>instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
> >>>updates the actual performance counters.
> >>I'm a bit concerned about the exception handling in the perf
> >>variable creation. But it appears to be similar to the other places
> >>where perf variables are created.
> >>
> >>Creating a 0-reporting perf counter if -UseCompressedKlassPointers
> >>seems consistent with the rest of the code.
> >>
> >>I'd say this is fine, but as Coleen mentioned you should verify this
> >>with Harold's change for CDS+CompressedOops.
> >Coleen, Mikael,
> >
> >I've rebased the change on top of hotspot-rt (which includes Harold's
> >change). I had to resolve some merge conflicts in metaspace.cpp.
> >
> >Please see the latest (and hopefully final) webrev at:
> >http://cr.openjdk.java.net/~ehelin/8014659/webrev.04/
> >
> >The incremental changes since the first webrev are listed below:
> >- http://cr.openjdk.java.net/~ehelin/8014659/webrev.03-04/
> >- http://cr.openjdk.java.net/~ehelin/8014659/webrev.02-03/
> >- http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/
> >- http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/
> >
> >I plan to push this to hotspot-rt as well, since the change now depends
> >on Harold's change.
> >
> >Thanks,
> >Erik
> >
> >>>The changes in metaspace.hpp/cpp were needed to get some additional data
> >>>from the metaspace data structures. The method
> >>>free_chunks_in_total(mdtype) was made public and the method
> >>>free_bytes(mdtype) was added. Some common functionality was extracted
> >>>into get_space_list(mdtype) which got rid of some duplicated code.
> >>>
> >>>The changes in:
> >>>- g1MonitorinSupport.cpp
> >>>- parallelScavengeHeap.cpp
> >>>- genCollectedHeap.cpp
> >>>- universe.cpp
> >>>are only "one-liners" that either update or initialize the new performance
> >>>counters.
> >>>
> >>>Changes to the testlibrary:
> >>>- Added Asserts.java for writing asserts like "assertTrue",
> >>>   "assertEquals", etc.
> >>>- Added PerfCounter.java and PerfCounters.java to make it easy to
> >>>   inspect performance counters for the currently running VM.
> >>>- Added InputArguments.java so a test can check the arguments it got
> >>>   passed.
> >>>- Added InMemoryJavaCompiler.java for compiling a string into bytecode.
> >>>   Useful for loading classes generated at runtime without using files.
> >>>- Added ByteCodeLoader.java for defining a new class when you already
> >>>   have the bytecode.
> >>The test code looks fine.
> >>
> >>/Mikael
> >>>Testing:
> >>>- Added the new test TestMetaspacePerfCounters.java
> >>>- JPRT
> >>>
> >>>Bug:
> >>>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
> >>>
> >>>Thanks,
> >>>Erik
> >>>
> 

From david.simms at oracle.com  Fri Aug 16 07:45:42 2013
From: david.simms at oracle.com (David Simms)
Date: Fri, 16 Aug 2013 16:45:42 +0200
Subject: RFR (S): 8022683 : JNI GetStringUTFChars should return NULL on
	allocation failure not abort the VM
Message-ID: <520E3B16.2040100@oracle.com>

Hello all,

Need reviewers on a JDK8 fix for: 
http://bugs.sun.com/view_bug.do?bug_id=8022683

Found the following functions need to return NULL as suggested by the 
JNI spec 
(http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html):

  * GetStringChars()
  * GetStringUTFChars()
  * Get<PrimitiveType>ArrayElements() family of array getters (same
    generating macro).

Although the specification suggests OOME may be thrown by certain 
functions, the documentation on the aforementioned functions does not 
suggest "throws". So they return NULL now without aborting the JVM as 
before.

It was assumed the meaning of "isCopy" is undefined given a NULL result, 
in keeping with the rest of jni.cpp.

Also discovered allocation.hpp macros missing proper argument bracketing 
(e.g. size passed in NEW_C_HEAP_ARRAY_RETURN_NULL()), fixed them up 
since I was there (and they caused trouble).

Webrev:

http://cr.openjdk.java.net/~dsimms/8022683/ 
<http://cr.openjdk.java.net/%7Edsimms/8022683/>

Testing:

Attached "unit test" to bug, naive test program to trigger OOM. It is 
not suitable for automated testing. Ideally require hooks into the JVM 
to simulate OOM during JNI calls.

Cheers
/David Simms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/10567d61/attachment.html 

From coleen.phillimore at oracle.com  Fri Aug 16 08:36:32 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 16 Aug 2013 11:36:32 -0400
Subject: RFR (M): 8014659: NPG: performance counters for compressed klass
	space
In-Reply-To: <20130816102208.GA2238@ehelin-thinkpad>
References: <20130814144906.GC2649@ehelin-thinkpad> <520CDD99.70403@oracle.com>
	<20130816102208.GA2238@ehelin-thinkpad>
Message-ID: <520E4700.4070805@oracle.com>


Erik,   Thank you for doing this.

A small nit - can you put () around list == NULL?

+  size_t reserved = list == NULL ? 0 : list->virtual_space_total();

Also, I thought I read this intent of this change was to separate 
CompressedClassSpaceCounters from MetaspaceCounters, but 
MetaspaceCounters still call MetaspaceAux::free_bytes() and functions 
with combine the two.   I don't think we should combine them anymore.   
I'm working on decoupling these two with LowMemoryThreshold counters 
(which you have to see).   It's sort of a mess from the users 
perspective when these are combined.

Does MetaspaceCounters make sense if the CompressedClassSpace is removed 
from the size calculations?

Thanks,
Coleen

On 8/16/2013 6:22 AM, Erik Helin wrote:
> On 2013-08-15, Mikael Gerdin wrote:
>> Erik,
>>
>> On 08/14/2013 04:49 PM, Erik Helin wrote:
>>> Hi all,
>>>
>>> this change adds performance counters for compressed class space.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
>>>
>>> Changes to hotspot:
>>> The main changes are in metaspaceCounters.hpp and metaspaceCounters.cpp,
>>> where the class MetaspaceCounters has been split up into
>>> MetaspaceCounters and MetaspacePerfCounters. MetaspaceCounters now owns
>>> an instance of MetaspacePerfCounters. The class
>>> CompressedClassSpaceCounters has been added which also has its own
>>> instance of MetaspacePerfCounters. MetaspacePerfCounters initializes and
>>> updates the actual performance counters.
>> I'm a bit concerned about the exception handling in the perf
>> variable creation. But it appears to be similar to the other places
>> where perf variables are created.
>>
>> Creating a 0-reporting perf counter if -UseCompressedKlassPointers
>> seems consistent with the rest of the code.
>>
>> I'd say this is fine, but as Coleen mentioned you should verify this
>> with Harold's change for CDS+CompressedOops.
> Coleen, Mikael,
>
> I've rebased the change on top of hotspot-rt (which includes Harold's
> change). I had to resolve some merge conflicts in metaspace.cpp.
>
> Please see the latest (and hopefully final) webrev at:
> http://cr.openjdk.java.net/~ehelin/8014659/webrev.04/
>
> The incremental changes since the first webrev are listed below:
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.03-04/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.02-03/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.01-02/
> - http://cr.openjdk.java.net/~ehelin/8014659/webrev.00-01/
>
> I plan to push this to hotspot-rt as well, since the change now depends
> on Harold's change.
>
> Thanks,
> Erik
>
>>> The changes in metaspace.hpp/cpp were needed to get some additional data
>> >from the metaspace data structures. The method
>>> free_chunks_in_total(mdtype) was made public and the method
>>> free_bytes(mdtype) was added. Some common functionality was extracted
>>> into get_space_list(mdtype) which got rid of some duplicated code.
>>>
>>> The changes in:
>>> - g1MonitorinSupport.cpp
>>> - parallelScavengeHeap.cpp
>>> - genCollectedHeap.cpp
>>> - universe.cpp
>>> are only "one-liners" that either update or initialize the new performance
>>> counters.
>>>
>>> Changes to the testlibrary:
>>> - Added Asserts.java for writing asserts like "assertTrue",
>>>    "assertEquals", etc.
>>> - Added PerfCounter.java and PerfCounters.java to make it easy to
>>>    inspect performance counters for the currently running VM.
>>> - Added InputArguments.java so a test can check the arguments it got
>>>    passed.
>>> - Added InMemoryJavaCompiler.java for compiling a string into bytecode.
>>>    Useful for loading classes generated at runtime without using files.
>>> - Added ByteCodeLoader.java for defining a new class when you already
>>>    have the bytecode.
>> The test code looks fine.
>>
>> /Mikael
>>> Testing:
>>> - Added the new test TestMetaspacePerfCounters.java
>>> - JPRT
>>>
>>> Bug:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
>>>
>>> Thanks,
>>> Erik
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/05cf6148/attachment.html 

From yumin.qi at oracle.com  Fri Aug 16 09:39:25 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 16 Aug 2013 09:39:25 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <520CF52B.6050000@oracle.com>
References: <520CF52B.6050000@oracle.com>
Message-ID: <520E55BD.6010200@oracle.com>

Any volunteers for this review?

Thanks
Yumin

On 8/15/2013 8:35 AM, Yumin Qi wrote:
> Hi,
>
>   Can I have your review for this small changes?
> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>
>    This is for a enhancement to add head/tail message to the logging 
> files to assist reading GC output.
>    1. modified prompt message if invalid arguments used for log rotating;
>    2. add time and file name message to log file head/tail.
>    3. for easily identify which log file is current, use file name 
> like <filename>.n.current, after it reaches maximum size, rename it to 
> <filename>.n
>         On Windows, there is no F_OK (existing test) definition, F_OK 
> is defined as "0" and for _access of VC++, it just describes:
>
> modevalue
>
> 	
>
> Checks file for
>
> 00
>
> 	
>
> Existence only
>
> 02
>
> 	
>
> Write-only
>
> 04
>
> 	
>
> Read-only
>
> 06
>
> 	
>
> Read and write
>
>
> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
> The definition are consistent with unistd.h.
>
>     Test: JPRT and jtreg.
>
>    Thanks
>    Yumin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/f978ee1a/attachment.html 

From david.r.chase at oracle.com  Fri Aug 16 13:05:02 2013
From: david.r.chase at oracle.com (David Chase)
Date: Fri, 16 Aug 2013 16:05:02 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
Message-ID: <858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>

How does this look?

void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
  if (_cp.is_null() || field_holder() != ik) {
    _cp = constantPoolHandle(Thread::current(), ik->constants());
    // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
    assert(field_holder() == ik, "must be already initialized to this class");
  }

> The fd::initialize call resets a fd previously pointing at a different field to a new field.
> This requires a shift in the field_holder.
> The call to initialize is fieldStreams.hpp, where a fd embedded in the stream object gets reused for successive fields.
> So I think this assert measures something meaningful.
> Perhaps the method should be named "reinitialize" or "reset" to emphasize the multiple use.
> 
> ? John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/a5754560/signature.asc 

From alejandro.murillo at oracle.com  Fri Aug 16 14:19:54 2013
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 16 Aug 2013 21:19:54 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 31 new changesets
Message-ID: <20130816212109.D0D3F48951@hg.openjdk.java.net>

Changeset: 0bbd1c775bef
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0bbd1c775bef

Added tag jdk8-b103 for changeset 6f9be7f87b96

! .hgtags

Changeset: ca0165daa6ec
Author:    sspitsyn
Date:      2013-08-06 16:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ca0165daa6ec

7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments
Summary: Restore the appendix argument after PopFrame() call
Reviewed-by: twisti, coleenp
Contributed-by: serguei.spitsyn at oracle.com

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp

Changeset: c54a3122f9c8
Author:    omajid
Date:      2013-08-06 12:28 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c54a3122f9c8

8022188: Make zero compile after 8016131 and 8016697
Reviewed-by: dholmes, twisti

! src/cpu/zero/vm/entryFrame_zero.hpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/stubGenerator_zero.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp

Changeset: 196aa14f9f29
Author:    dholmes
Date:      2013-08-06 21:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/196aa14f9f29

Merge


Changeset: 195ff07bc7f6
Author:    dsamersoff
Date:      2013-08-07 19:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/195ff07bc7f6

8021771: warning stat64 is deprecated - when building on OSX 10.7.5
Summary: stat64 have to be replaced with stat
Reviewed-by: dholmes, kmo
Contributed-by: rednaxelafx at gmail.com

! src/os/bsd/vm/attachListener_bsd.cpp

Changeset: 31f3b1e1c5e5
Author:    dcubed
Date:      2013-08-08 09:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/31f3b1e1c5e5

8016601: Unable to build hsx24 on Windows using project creator and Visual Studio
Summary: ProjectCreator tool is modified to support two new options: '-relativeAltSrcInclude' and '-altRelativeInclude' which prevents IDE linker errors. Also fixed some cmd line build linker warnings. Misc cleanups.
Reviewed-by: rdurbin, coleenp

! make/windows/create.bat
! make/windows/create_obj_files.sh
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/trace.make
! make/windows/makefiles/vm.make
! src/share/tools/ProjectCreator/BuildConfig.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java

Changeset: c661fa2e5189
Author:    iklam
Date:      2013-08-08 14:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c661fa2e5189

8022093: syntax error near "umpiconninfo_t" -- when building on Solaris 10
Summary: Added extra help message in make/solaris/makefiles/dtrace.make
Reviewed-by: dholmes, sspitsyn

! make/solaris/makefiles/dtrace.make

Changeset: 57ac7245594c
Author:    minqi
Date:      2013-08-08 15:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/57ac7245594c

8019583: [TESTBUG] runtime/7107135 always passes
Summary: If java test return none zero, the value will be override by 'if' statement, the exit value will always '0' and pass. Fix by recording the result in a variable.
Reviewed-by: coleenp, dholmes, iklam
Contributed-by: yumin.qi at oracle.com

! test/runtime/7107135/Test7107135.sh

Changeset: 6222a021d582
Author:    minqi
Date:      2013-08-08 20:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6222a021d582

Merge


Changeset: 98aa538fd97e
Author:    mikael
Date:      2013-08-09 09:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/98aa538fd97e

8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2
Summary: Add support for recognizing Windows 8.1 and Server 2012 R2 and minor cleanup
Reviewed-by: coleenp, dsamersoff

! src/os/windows/vm/os_windows.cpp

Changeset: ed7c17e7d45b
Author:    dcubed
Date:      2013-08-09 13:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ed7c17e7d45b

Merge


Changeset: 7b03590c334b
Author:    dcubed
Date:      2013-08-09 15:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7b03590c334b

Merge


Changeset: bd0e82136b03
Author:    iklam
Date:      2013-08-10 10:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/bd0e82136b03

8022740: Visual 2008 IDE build is broken
Summary: Fixed project generation code, and added warning to upgrade to VS 2008 SP1.
Reviewed-by: dcubed, ccheung

! make/windows/projectfiles/common/Makefile
! src/share/tools/ProjectCreator/FileTreeCreator.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC7.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java

Changeset: 85147f28faba
Author:    coleenp
Date:      2013-08-12 17:24 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/85147f28faba

8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
Summary: ActiveMethodOopsCache was used to keep track of old versions of some methods that are cached in Universe but is buggy with permgen removal and not needed anymore
Reviewed-by: sspitsyn, dcubed, mseledtsov

! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! test/runtime/RedefineObject/Agent.java
! test/runtime/RedefineObject/TestRedefineObject.java
+ test/runtime/RedefineObject/WalkThroughInvoke.java

Changeset: d1034bd8cefc
Author:    adlertz
Date:      2013-08-07 17:56 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d1034bd8cefc

8022284: Hide internal data structure in PhaseCFG
Summary: Hide private node to block mapping using public interface
Reviewed-by: kvn, roland

! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/output.hpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ce8969c36762
Author:    adlertz
Date:      2013-08-07 18:04 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ce8969c36762

8022475: Remove unneeded ad-files
Summary: Remove .ad files that are not used
Reviewed-by: kvn

! make/bsd/makefiles/adlc.make
! make/linux/makefiles/adlc.make
! make/solaris/makefiles/adlc.make
! make/windows/makefiles/adlc.make
- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 5394ec69f112
Author:    rbackman
Date:      2013-08-09 18:05 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5394ec69f112

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 11237ee74aae
Author:    iignatyev
Date:      2013-08-10 10:01 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/11237ee74aae

8019915: whitebox testClearMethodStateTest fails with tiered on sparc
Summary: 'compileonly' directive has beens added to each 'compiler/whitebox' test
Reviewed-by: kvn

! test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/compiler/whitebox/SetForceInlineMethodTest.java

Changeset: bcc4f6f54d83
Author:    kvn
Date:      2013-08-14 10:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/bcc4f6f54d83

8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag
Summary: Replace MAX_UNROLL constant with new C2 LoopMaxUnroll flag.
Reviewed-by: roland

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/loopTransform.cpp

Changeset: 56b94e55267a
Author:    rbackman
Date:      2013-08-15 15:26 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/56b94e55267a

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 9766f73e770d
Author:    stefank
Date:      2013-05-31 14:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9766f73e770d

8022880: False sharing between PSPromotionManager instances
Summary: Pad the PSPromotionManager instances in the manager array.
Reviewed-by: brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_implementation/parNew/parOopClosures.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
+ src/share/vm/memory/padded.hpp
+ src/share/vm/memory/padded.inline.hpp
! src/share/vm/utilities/debug.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 330dfb0476f4
Author:    brutisso
Date:      2013-08-14 09:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/330dfb0476f4

8022800: Use specific generations rather than generation iteration
Reviewed-by: jmasa, ehelin

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genRemSet.hpp

Changeset: 3f22cbf5275d
Author:    brutisso
Date:      2013-08-14 10:55 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/3f22cbf5275d

Merge


Changeset: 5d9995d16b26
Author:    ehelin
Date:      2013-08-14 13:49 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5d9995d16b26

8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining
Reviewed-by: coleenp, mgerdin

! src/share/vm/utilities/exceptions.hpp

Changeset: bd902affe102
Author:    brutisso
Date:      2013-08-15 10:05 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/bd902affe102

8023021: Unnecessary clearing of the card table introduced by the fix for JDK-8023013
Reviewed-by: stefank, ehelin

! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genRemSet.hpp

Changeset: 274ce305e5b9
Author:    ehelin
Date:      2013-08-13 18:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/274ce305e5b9

8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0
Reviewed-by: stefank, brutisso, sjohanss

! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp

Changeset: 33d39b75663f
Author:    ehelin
Date:      2013-08-15 06:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/33d39b75663f

Merge


Changeset: 5a62937e55b3
Author:    brutisso
Date:      2013-08-16 09:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5a62937e55b3

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 580430d131cc
Author:    amurillo
Date:      2013-08-16 04:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/580430d131cc

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 104743074675
Author:    amurillo
Date:      2013-08-16 04:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/104743074675

Added tag hs25-b46 for changeset 580430d131cc

! .hgtags

Changeset: 37165c3618a3
Author:    amurillo
Date:      2013-08-16 04:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/37165c3618a3

8023152: new hotspot build - hs25-b47
Reviewed-by: jcoomes

! make/hotspot_version


From yumin.qi at oracle.com  Fri Aug 16 16:13:33 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 16 Aug 2013 16:13:33 -0700
Subject: RFR: 8023188: Unsafe double store on bsd is broken
Message-ID: <520EB21D.1030207@oracle.com>

Hi,

   Please have a review of this small change which is a typo mistake 
(but lead to this bug) in fix of
   8016538: volatile double access via Unsafe.cpp is not atomic

http://cr.openjdk.java.net/~minqi/8023188/webrev00 
<http://cr.openjdk.java.net/%7Eminqi/8023188/webrev00>

    Tested JPRT and java-concurrency-torture.jar (the original testing case)

Thanks
Yumin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/508ef8d3/attachment.html 

From daniel.daugherty at oracle.com  Fri Aug 16 16:51:18 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 16 Aug 2013 17:51:18 -0600
Subject: RFR: 8023188: Unsafe double store on bsd is broken
In-Reply-To: <520EB21D.1030207@oracle.com>
References: <520EB21D.1030207@oracle.com>
Message-ID: <520EBAF6.6020107@oracle.com>

Thumbs up!

Please make sure you hear back from your original reviewers for this fix:

8016538: volatile double access via Unsafe.cpp is not atomic
Summary: volatile jdouble load/store is not atomic, fix by using of 
existing volatile jlong operations which are atomic for jdouble.
Reviewed-by: kvn, vladidan, jrose
Contributed-by: david.holmes at oracle.com

Just to make sure that they are on board here.

Dan


On 8/16/13 5:13 PM, Yumin Qi wrote:
> Hi,
>
>   Please have a review of this small change which is a typo mistake 
> (but lead to this bug) in fix of
>   8016538: volatile double access via Unsafe.cpp is not atomic
>
> http://cr.openjdk.java.net/~minqi/8023188/webrev00 
> <http://cr.openjdk.java.net/%7Eminqi/8023188/webrev00>
>
>    Tested JPRT and java-concurrency-torture.jar (the original testing 
> case)
>
> Thanks
> Yumin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/c6613714/attachment-0001.html 

From yumin.qi at oracle.com  Fri Aug 16 17:24:34 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 16 Aug 2013 17:24:34 -0700
Subject: RFR: 8023188: Unsafe double store on bsd is broken
In-Reply-To: <520EBAF6.6020107@oracle.com>
References: <520EB21D.1030207@oracle.com> <520EBAF6.6020107@oracle.com>
Message-ID: <520EC2C2.40708@oracle.com>

Thanks Dan for the review.

Thanks
Yumin

On 8/16/2013 4:51 PM, Daniel D. Daugherty wrote:
> Thumbs up!
>
> Please make sure you hear back from your original reviewers for this fix:
>
> 8016538: volatile double access via Unsafe.cpp is not atomic
> Summary: volatile jdouble load/store is not atomic, fix by using of 
> existing volatile jlong operations which are atomic for jdouble.
> Reviewed-by: kvn, vladidan, jrose
> Contributed-by: david.holmes at oracle.com
>
> Just to make sure that they are on board here.
>
> Dan
>
>
> On 8/16/13 5:13 PM, Yumin Qi wrote:
>> Hi,
>>
>>   Please have a review of this small change which is a typo mistake 
>> (but lead to this bug) in fix of
>>   8016538: volatile double access via Unsafe.cpp is not atomic
>>
>> http://cr.openjdk.java.net/~minqi/8023188/webrev00 
>> <http://cr.openjdk.java.net/%7Eminqi/8023188/webrev00>
>>
>>    Tested JPRT and java-concurrency-torture.jar (the original testing 
>> case)
>>
>> Thanks
>> Yumin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/a164a73e/attachment.html 

From daniel.daugherty at oracle.com  Fri Aug 16 18:12:56 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Sat, 17 Aug 2013 01:12:56 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 19 new changesets
Message-ID: <20130817011334.73A9648958@hg.openjdk.java.net>

Changeset: d1034bd8cefc
Author:    adlertz
Date:      2013-08-07 17:56 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1034bd8cefc

8022284: Hide internal data structure in PhaseCFG
Summary: Hide private node to block mapping using public interface
Reviewed-by: kvn, roland

! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/output.hpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ce8969c36762
Author:    adlertz
Date:      2013-08-07 18:04 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ce8969c36762

8022475: Remove unneeded ad-files
Summary: Remove .ad files that are not used
Reviewed-by: kvn

! make/bsd/makefiles/adlc.make
! make/linux/makefiles/adlc.make
! make/solaris/makefiles/adlc.make
! make/windows/makefiles/adlc.make
- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 5394ec69f112
Author:    rbackman
Date:      2013-08-09 18:05 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5394ec69f112

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 11237ee74aae
Author:    iignatyev
Date:      2013-08-10 10:01 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/11237ee74aae

8019915: whitebox testClearMethodStateTest fails with tiered on sparc
Summary: 'compileonly' directive has beens added to each 'compiler/whitebox' test
Reviewed-by: kvn

! test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/compiler/whitebox/SetForceInlineMethodTest.java

Changeset: bcc4f6f54d83
Author:    kvn
Date:      2013-08-14 10:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bcc4f6f54d83

8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag
Summary: Replace MAX_UNROLL constant with new C2 LoopMaxUnroll flag.
Reviewed-by: roland

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/loopTransform.cpp

Changeset: 56b94e55267a
Author:    rbackman
Date:      2013-08-15 15:26 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56b94e55267a

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 9766f73e770d
Author:    stefank
Date:      2013-05-31 14:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9766f73e770d

8022880: False sharing between PSPromotionManager instances
Summary: Pad the PSPromotionManager instances in the manager array.
Reviewed-by: brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_implementation/parNew/parOopClosures.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
+ src/share/vm/memory/padded.hpp
+ src/share/vm/memory/padded.inline.hpp
! src/share/vm/utilities/debug.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 330dfb0476f4
Author:    brutisso
Date:      2013-08-14 09:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/330dfb0476f4

8022800: Use specific generations rather than generation iteration
Reviewed-by: jmasa, ehelin

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genRemSet.hpp

Changeset: 3f22cbf5275d
Author:    brutisso
Date:      2013-08-14 10:55 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3f22cbf5275d

Merge


Changeset: 5d9995d16b26
Author:    ehelin
Date:      2013-08-14 13:49 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5d9995d16b26

8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining
Reviewed-by: coleenp, mgerdin

! src/share/vm/utilities/exceptions.hpp

Changeset: bd902affe102
Author:    brutisso
Date:      2013-08-15 10:05 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bd902affe102

8023021: Unnecessary clearing of the card table introduced by the fix for JDK-8023013
Reviewed-by: stefank, ehelin

! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genRemSet.hpp

Changeset: 274ce305e5b9
Author:    ehelin
Date:      2013-08-13 18:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/274ce305e5b9

8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0
Reviewed-by: stefank, brutisso, sjohanss

! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp

Changeset: 33d39b75663f
Author:    ehelin
Date:      2013-08-15 06:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/33d39b75663f

Merge


Changeset: 5a62937e55b3
Author:    brutisso
Date:      2013-08-16 09:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5a62937e55b3

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 0bbd1c775bef
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0bbd1c775bef

Added tag jdk8-b103 for changeset 6f9be7f87b96

! .hgtags

Changeset: 580430d131cc
Author:    amurillo
Date:      2013-08-16 04:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/580430d131cc

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 104743074675
Author:    amurillo
Date:      2013-08-16 04:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/104743074675

Added tag hs25-b46 for changeset 580430d131cc

! .hgtags

Changeset: 37165c3618a3
Author:    amurillo
Date:      2013-08-16 04:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/37165c3618a3

8023152: new hotspot build - hs25-b47
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: e5003079dfa5
Author:    dcubed
Date:      2013-08-16 10:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e5003079dfa5

Merge

! src/share/vm/utilities/globalDefinitions.hpp


From calvin.cheung at oracle.com  Fri Aug 16 18:26:25 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 16 Aug 2013 18:26:25 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <520CF52B.6050000@oracle.com>
References: <520CF52B.6050000@oracle.com>
Message-ID: <520ED141.6050108@oracle.com>

Couple of minor comments in ostream.cpp:

1)
   479   char time_msg[256];
  480   char time_str[64];
  481   char renamed_file_name[256];

I think you can replace 256 with MAX_PATH. However, we define MAX_PATH 
as (2 * K) in unix platforms. So it maybe too large of a buffer for this 
purpose. On windows, I think it is defined as 256.

In the same file, there's
     static const int buffer_length = 32;
in outputStream::date_stamp().

I'm thinking you can have a #define for the size for time_str and use 
the same #define in
outputStream::date_stamp().

2)
int jio_snprintf(char *str, size_t count, const char *fmt, ...)

The return value of jio_snprintf() isn't checked.
It could return -1 from calling _vsnprintf(). However, I don't see the 
return status being check in the existing code. So I'm not sure if it is 
a must check.

3)

516 if (access(renamed_file_name, NOT_WINDOWS(F_OK) WINDOWS_ONLY(0)) == 
0) {

543 if (access(renamed_file_name, NOT_WINDOWS(F_OK) WINDOWS_ONLY(0)) == 0) {

You can use ERROR_SUCCESS instead of 0 for the WINDOWS_ONLY part.

Calvin

On 8/15/2013 8:35 AM, Yumin Qi wrote:
> Hi,
>
>   Can I have your review for this small changes?
> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>
>    This is for a enhancement to add head/tail message to the logging 
> files to assist reading GC output.
>    1. modified prompt message if invalid arguments used for log rotating;
>    2. add time and file name message to log file head/tail.
>    3. for easily identify which log file is current, use file name 
> like <filename>.n.current, after it reaches maximum size, rename it to 
> <filename>.n
>         On Windows, there is no F_OK (existing test) definition, F_OK 
> is defined as "0" and for _access of VC++, it just describes:
>
> modevalue
>
> 	
>
> Checks file for
>
> 00
>
> 	
>
> Existence only
>
> 02
>
> 	
>
> Write-only
>
> 04
>
> 	
>
> Read-only
>
> 06
>
> 	
>
> Read and write
>
>
> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
> The definition are consistent with unistd.h.
>
>     Test: JPRT and jtreg.
>
>    Thanks
>    Yumin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/df7c27b9/attachment-0001.html 

From yumin.qi at oracle.com  Fri Aug 16 19:39:13 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 16 Aug 2013 19:39:13 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <520ED141.6050108@oracle.com>
References: <520CF52B.6050000@oracle.com> <520ED141.6050108@oracle.com>
Message-ID: <520EE251.5070506@oracle.com>

Calvin,
   Thanks for the review,
   See embedded.

On 8/16/2013 6:26 PM, Calvin Cheung wrote:
> Couple of minor comments in ostream.cpp:
>
> 1)
>   479   char time_msg[256];
>  480   char time_str[64];
>  481   char renamed_file_name[256];
>
> I think you can replace 256 with MAX_PATH. However, we define MAX_PATH 
> as (2 * K) in unix platforms. So it maybe too large of a buffer for 
> this purpose. On windows, I think it is defined as 256.
>
> In the same file, there's
>     static const int buffer_length = 32;
> in outputStream::date_stamp().
>
> I'm thinking you can have a #define for the size for time_str and use 
> the same #define in
> outputStream::date_stamp().
>
I considered using MAX_PATH but it is too big for this purpose so take 
current solution. For time string we may use buffer_length, I will 
change that.
> 2)
> int jio_snprintf(char *str, size_t count, const char *fmt, ...)
>
> The return value of jio_snprintf() isn't checked.
> It could return -1 from calling _vsnprintf(). However, I don't see the 
> return status being check in the existing code. So I'm not sure if it 
> is a must check.
>
This return value only indicates the writing of chars finished and 
number of chars is less or equals to count (buffer not over flowed). If 
copy up to count and string truncated it is still OK, the buffer will 
contain partial strings but not all. So usually we don't check its 
return value.
> 3)
>
> 516 if (access(renamed_file_name, NOT_WINDOWS(F_OK) WINDOWS_ONLY(0)) 
> == 0) {
>
> 543 if (access(renamed_file_name, NOT_WINDOWS(F_OK) WINDOWS_ONLY(0)) 
> == 0) {
>
> You can use ERROR_SUCCESS instead of 0 for the WINDOWS_ONLY part.
>
Using ERROR_SUCCESS will mislead reading code since it is usually used 
for a return value from Windows API call. In fact there is definitions 
in io.h of Visual C++:
/* File attribute constants for _findfirst() */

#define _A_NORMAL       0x00    /* Normal file - No read/write 
restrictions */
#define _A_RDONLY       0x01    /* Read only file */
#define _A_HIDDEN       0x02    /* Hidden file */
#define _A_SYSTEM       0x04    /* System file */
#define _A_SUBDIR       0x10    /* Subdirectory */
#define _A_ARCH         0x20    /* Archive file */

But I would like to use '0' here to not make the symbol complicate for 
reading.

Thanks
Yumin
> Calvin
>
> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>> Hi,
>>
>>   Can I have your review for this small changes?
>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>
>>    This is for a enhancement to add head/tail message to the logging 
>> files to assist reading GC output.
>>    1. modified prompt message if invalid arguments used for log rotating;
>>    2. add time and file name message to log file head/tail.
>>    3. for easily identify which log file is current, use file name 
>> like <filename>.n.current, after it reaches maximum size, rename it 
>> to <filename>.n
>>         On Windows, there is no F_OK (existing test) definition, F_OK 
>> is defined as "0" and for _access of VC++, it just describes:
>>
>> modevalue
>>
>> 	
>>
>> Checks file for
>>
>> 00
>>
>> 	
>>
>> Existence only
>>
>> 02
>>
>> 	
>>
>> Write-only
>>
>> 04
>>
>> 	
>>
>> Read-only
>>
>> 06
>>
>> 	
>>
>> Read and write
>>
>>
>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>> The definition are consistent with unistd.h.
>>
>>     Test: JPRT and jtreg.
>>
>>    Thanks
>>    Yumin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/3314ee0c/attachment.html 

From john.r.rose at oracle.com  Fri Aug 16 22:41:48 2013
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 16 Aug 2013 22:41:48 -0700
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
Message-ID: <94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>

On Aug 16, 2013, at 1:05 PM, David Chase <david.r.chase at oracle.com> wrote:

> How does this look?
> 
> void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
>  if (_cp.is_null() || field_holder() != ik) {
>    _cp = constantPoolHandle(Thread::current(), ik->constants());
>    // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
>    assert(field_holder() == ik, "must be already initialized to this class");

Good.

As a side note, this bit of code (and many others) assume that there is a 1-1 correspondence between constant pools and instance klasses.

I hope we can change this some day; the tracking bug is http://bugs.sun.com/view_bug.do?bug_id=6711913

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130816/ec507de3/attachment.html 

From david.holmes at oracle.com  Sun Aug 18 01:12:00 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 18 Aug 2013 18:12:00 +1000
Subject: RFR: 8023188: Unsafe double store on bsd is broken
In-Reply-To: <520EBAF6.6020107@oracle.com>
References: <520EB21D.1030207@oracle.com> <520EBAF6.6020107@oracle.com>
Message-ID: <521081D0.10609@oracle.com>

On 17/08/2013 9:51 AM, Daniel D. Daugherty wrote:
> Thumbs up!

Ditto.

> Please make sure you hear back from your original reviewers for this fix:
>
> 8016538: volatile double access via Unsafe.cpp is not atomic
> Summary: volatile jdouble load/store is not atomic, fix by using of
> existing volatile jlong operations which are atomic for jdouble.
> Reviewed-by: kvn, vladidan, jrose
> Contributed-by: david.holmes at oracle.com
>
> Just to make sure that they are on board here.

There's really nothing to be "onboard" with. The cast to double should 
have been a cast to long - simple typo. The surprising thing is that the 
OSX compiler didn't complain about it.

Cheers,
David

> Dan
>
>
> On 8/16/13 5:13 PM, Yumin Qi wrote:
>> Hi,
>>
>>   Please have a review of this small change which is a typo mistake
>> (but lead to this bug) in fix of
>>   8016538: volatile double access via Unsafe.cpp is not atomic
>>
>> http://cr.openjdk.java.net/~minqi/8023188/webrev00
>> <http://cr.openjdk.java.net/%7Eminqi/8023188/webrev00>
>>
>>    Tested JPRT and java-concurrency-torture.jar (the original testing
>> case)
>>
>> Thanks
>> Yumin
>

From david.r.chase at oracle.com  Sun Aug 18 15:24:14 2013
From: david.r.chase at oracle.com (David Chase)
Date: Sun, 18 Aug 2013 18:24:14 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
	<94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
Message-ID: <F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>

A question about err_msg_res -- should that generally be used in place of err_msg,
or only in certain source directories, and if so, which ones?

On 2013-08-17, at 1:41 AM, John Rose <john.r.rose at oracle.com> wrote:

> On Aug 16, 2013, at 1:05 PM, David Chase <david.r.chase at oracle.com> wrote:
> 
>> How does this look?
>> 
>> void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
>>  if (_cp.is_null() || field_holder() != ik) {
>>    _cp = constantPoolHandle(Thread::current(), ik->constants());
>>    // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
>>    assert(field_holder() == ik, "must be already initialized to this class");
> 
> Good.
> 
> As a side note, this bit of code (and many others) assume that there is a 1-1 correspondence between constant pools and instance klasses.
> 
> I hope we can change this some day; the tracking bug is http://bugs.sun.com/view_bug.do?bug_id=6711913
> 
> ? John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130818/d413a3bf/signature.asc 

From suenaga.yasumasa at lab.ntt.co.jp  Sun Aug 18 17:34:08 2013
From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga)
Date: Mon, 19 Aug 2013 09:34:08 +0900
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <520CF52B.6050000@oracle.com>
References: <520CF52B.6050000@oracle.com>
Message-ID: <52116800.3040901@lab.ntt.co.jp>

Hi Yumin,

I've posted a RFE and patch for adding timestamp, PID, etc to log filename.

JDK-6950794 : Make the GC log file name parameterized
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6950794
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html

Your patch writes timestamp into logfile.
Howeverm, in production system, we may want to check log generation through
log filename. (e.g. ls command at Linux)

Could you check my patch?


Thanks,

Yasumasa

On 2013/08/16 0:35, Yumin Qi wrote:
> Hi,
>
>    Can I have your review for this small changes?
> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>
>     This is for a enhancement to add head/tail message to the logging files to assist reading GC output.
>     1. modified prompt message if invalid arguments used for log rotating;
>     2. add time and file name message to log file head/tail.
>     3. for easily identify which log file is current, use file name like <filename>.n.current, after it reaches maximum size, rename it to <filename>.n
>          On Windows, there is no F_OK (existing test) definition, F_OK is defined as "0" and for _access of VC++, it just describes:
>
> modevalue
>
> 	
>
> Checks file for
>
> 00
>
> 	
>
> Existence only
>
> 02
>
> 	
>
> Write-only
>
> 04
>
> 	
>
> Read-only
>
> 06
>
> 	
>
> Read and write
>
>
> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
> The definition are consistent with unistd.h.
>
>      Test: JPRT and jtreg.
>
>     Thanks
>     Yumin


From david.holmes at oracle.com  Sun Aug 18 20:51:17 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 19 Aug 2013 13:51:17 +1000
Subject: RFR (S): 8022683 : JNI GetStringUTFChars should return NULL on
	allocation failure not abort the VM
In-Reply-To: <520E3B16.2040100@oracle.com>
References: <520E3B16.2040100@oracle.com>
Message-ID: <52119635.1050908@oracle.com>

Hi David,

On 17/08/2013 12:45 AM, David Simms wrote:
> Hello all,
>
> Need reviewers on a JDK8 fix for:
> http://bugs.sun.com/view_bug.do?bug_id=8022683
>
> Found the following functions need to return NULL as suggested by the
> JNI spec
> (http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html):
>
>   * GetStringChars()
>   * GetStringUTFChars()
>   * Get<PrimitiveType>ArrayElements() family of array getters (same
>     generating macro).
>
> Although the specification suggests OOME may be thrown by certain
> functions, the documentation on the aforementioned functions does not
> suggest "throws". So they return NULL now without aborting the JVM as
> before.

There is always come contention with the JNI spec as to whether the 
intent is as defined by the original JNI spec book, or whether it is 
reflected in what is considered the "official spec". :)

> It was assumed the meaning of "isCopy" is undefined given a NULL result,
> in keeping with the rest of jni.cpp.

Even so I think it preferable to not set it unless the operation succeeds.

> Also discovered allocation.hpp macros missing proper argument bracketing
> (e.g. size passed in NEW_C_HEAP_ARRAY_RETURN_NULL()), fixed them up
> since I was there (and they caused trouble).

I can only see size causing a problem because it is used in an 
expression. The rest seems somewhat overkill.

> Webrev:
>
> http://cr.openjdk.java.net/~dsimms/8022683/
> <http://cr.openjdk.java.net/%7Edsimms/8022683/>

One concern I have is in how the dtrace probes will handle things if 
buf/result is NULL?

Thanks,
David

> Testing:
>
> Attached "unit test" to bug, naive test program to trigger OOM. It is
> not suitable for automated testing. Ideally require hooks into the JVM
> to simulate OOM during JNI calls.
>
> Cheers
> /David Simms

From david.holmes at oracle.com  Sun Aug 18 21:04:09 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 19 Aug 2013 14:04:09 +1000
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
	<94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
	<F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>
Message-ID: <52119939.50205@oracle.com>

On 19/08/2013 8:24 AM, David Chase wrote:
> A question about err_msg_res -- should that generally be used in place of err_msg,
> or only in certain source directories, and if so, which ones?

I can't answer that but be aware that there is an issue with using 
err_msg_res as it is unclear as to whom has responsibility for ensuring 
there is a ResourceMark on the stack. There's an open bug on that - 8022187.

David

> On 2013-08-17, at 1:41 AM, John Rose <john.r.rose at oracle.com> wrote:
>
>> On Aug 16, 2013, at 1:05 PM, David Chase <david.r.chase at oracle.com> wrote:
>>
>>> How does this look?
>>>
>>> void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
>>>   if (_cp.is_null() || field_holder() != ik) {
>>>     _cp = constantPoolHandle(Thread::current(), ik->constants());
>>>     // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
>>>     assert(field_holder() == ik, "must be already initialized to this class");
>>
>> Good.
>>
>> As a side note, this bit of code (and many others) assume that there is a 1-1 correspondence between constant pools and instance klasses.
>>
>> I hope we can change this some day; the tracking bug is http://bugs.sun.com/view_bug.do?bug_id=6711913
>>
>> ? John
>

From staffan.larsen at oracle.com  Mon Aug 19 02:08:00 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 19 Aug 2013 11:08:00 +0200
Subject: RFR: 8022808: Kitchensink hangs on macos
Message-ID: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>

We are using the mach thread port name as the os thread identifier on OS X. We get this value by calling mach_thread_self(), but we (I) didn't realize that this "port" resource is reference counted and mach_thread_self() increases the reference count, but we never call mach_port_deallocate() to decrease the reference count. This leads to a resource leak and eventually mach_thread_self() will return 0 to indicate that we are out of ports. Running out of ports causes the pthreads implementation (which is built on top of mach) to spin forever in some calls (most notably in this case pthread_kill()).

One way to fix this is to make sure we call mach_port_deallocate() for each call to mach_thread_self(). However, this adds extra complexity to the code and also makes it slower. Another solution is to ask pthreads for the mach port name that it already has. Pthreads provides the function pthread_mach_thread_np() for this purpose. In this case there is no need to deallocate the port since pthread_mach_thread_np() will not increase the reference count (and pthreads will call deallocate on the port once the thread terminates).

This fix has been verified by seeing that the number of ports the process has allocated does not increase in Activity Monitor (or top). It has also passed JPRT testing on all platforms.

webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
(there is not publicly visible bug for this)

Thanks,
/Staffan

From rickard.backman at oracle.com  Mon Aug 19 03:15:45 2013
From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=)
Date: Mon, 19 Aug 2013 12:15:45 +0200
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
Message-ID: <48AF30C9-72B0-42E9-9CD4-2BD79B323CCD@oracle.com>

Staffan,

the change looks good. (Not a Reviewer).

One thing to point out though, if we would leak ports the following line would get stuck in an infinite loop
(pthread_mach_thread_np calls _pthread_lookup_thread which calls _pthread_find_thread which will spin forever if the ports part of the pthread struct is zero - which it will be if we are out of ports). 

mach_port_t thread_id = ::pthread_mach_thread_np(::pthread_self());

That makes the guarantee line redundant since it will never be reached.
Maybe it would be good if we had a better way of checking if we are out of resources.

/R

On Aug 19, 2013, at 11:08 AM, Staffan Larsen wrote:

> We are using the mach thread port name as the os thread identifier on OS X. We get this value by calling mach_thread_self(), but we (I) didn't realize that this "port" resource is reference counted and mach_thread_self() increases the reference count, but we never call mach_port_deallocate() to decrease the reference count. This leads to a resource leak and eventually mach_thread_self() will return 0 to indicate that we are out of ports. Running out of ports causes the pthreads implementation (which is built on top of mach) to spin forever in some calls (most notably in this case pthread_kill()).
> 
> One way to fix this is to make sure we call mach_port_deallocate() for each call to mach_thread_self(). However, this adds extra complexity to the code and also makes it slower. Another solution is to ask pthreads for the mach port name that it already has. Pthreads provides the function pthread_mach_thread_np() for this purpose. In this case there is no need to deallocate the port since pthread_mach_thread_np() will not increase the reference count (and pthreads will call deallocate on the port once the thread terminates).
> 
> This fix has been verified by seeing that the number of ports the process has allocated does not increase in Activity Monitor (or top). It has also passed JPRT testing on all platforms.
> 
> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
> (there is not publicly visible bug for this)
> 
> Thanks,
> /Staffan


From staffan.larsen at oracle.com  Mon Aug 19 04:03:21 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 19 Aug 2013 13:03:21 +0200
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <48AF30C9-72B0-42E9-9CD4-2BD79B323CCD@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
	<48AF30C9-72B0-42E9-9CD4-2BD79B323CCD@oracle.com>
Message-ID: <7C1C69DB-A068-4124-88CE-46A7ABD412F7@oracle.com>

Yeah... I don't know a way to check that without calling mach_thread_self. Ideally pthreads should fail on pthread_create if we are out of resources, but that doesn't seem to be the case.

/Staffan

On 19 aug 2013, at 12:15, Rickard B?ckman <rickard.backman at oracle.com> wrote:

> Staffan,
> 
> the change looks good. (Not a Reviewer).
> 
> One thing to point out though, if we would leak ports the following line would get stuck in an infinite loop
> (pthread_mach_thread_np calls _pthread_lookup_thread which calls _pthread_find_thread which will spin forever if the ports part of the pthread struct is zero - which it will be if we are out of ports). 
> 
> mach_port_t thread_id = ::pthread_mach_thread_np(::pthread_self());
> 
> That makes the guarantee line redundant since it will never be reached.
> Maybe it would be good if we had a better way of checking if we are out of resources.
> 
> /R
> 
> On Aug 19, 2013, at 11:08 AM, Staffan Larsen wrote:
> 
>> We are using the mach thread port name as the os thread identifier on OS X. We get this value by calling mach_thread_self(), but we (I) didn't realize that this "port" resource is reference counted and mach_thread_self() increases the reference count, but we never call mach_port_deallocate() to decrease the reference count. This leads to a resource leak and eventually mach_thread_self() will return 0 to indicate that we are out of ports. Running out of ports causes the pthreads implementation (which is built on top of mach) to spin forever in some calls (most notably in this case pthread_kill()).
>> 
>> One way to fix this is to make sure we call mach_port_deallocate() for each call to mach_thread_self(). However, this adds extra complexity to the code and also makes it slower. Another solution is to ask pthreads for the mach port name that it already has. Pthreads provides the function pthread_mach_thread_np() for this purpose. In this case there is no need to deallocate the port since pthread_mach_thread_np() will not increase the reference count (and pthreads will call deallocate on the port once the thread terminates).
>> 
>> This fix has been verified by seeing that the number of ports the process has allocated does not increase in Activity Monitor (or top). It has also passed JPRT testing on all platforms.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
>> (there is not publicly visible bug for this)
>> 
>> Thanks,
>> /Staffan
> 


From harold.seigel at oracle.com  Mon Aug 19 06:52:26 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Mon, 19 Aug 2013 09:52:26 -0400
Subject: Request for Review 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh
	fails on 64-bit solaris
In-Reply-To: <5203F024.9040006@oracle.com>
References: <5203F024.9040006@oracle.com>
Message-ID: <5212231A.7070704@oracle.com>

Hi,

I'm resending this RFR because I did not get any reviewers the first 
time.  If you have chance, please take a look.

Thanks, Harold

On 8/8/2013 3:23 PM, harold seigel wrote:
> Hi,
>
> Please review this change to fix bug 7121403.  The test was rewritten 
> in Java and modified to properly determine when it is running on 
> 64-bit Solaris.
>
> The fix was tested by running the new test on 32-bit Linux, Solaris 
> Sparc, Solaris X86, and 64-bit Linux.
>
> webrev: http://cr.openjdk.java.net/~hseigel/bug_7121403/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_7121403/>
>
> bug: http://bugs.sun.com/view_bug.do?bug_id=7121403
>
> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-7121403
>
> Thanks! Harold


From gerard.ziemski at oracle.com  Mon Aug 19 08:33:08 2013
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Mon, 19 Aug 2013 10:33:08 -0500
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
Message-ID: <52123AB4.3090609@oracle.com>

hi Staffan,

Why are we using the the "::" C++ name space before mach/pthread C APIs 
calls?


cheers

On 8/19/2013 4:08 AM, Staffan Larsen wrote:
> We are using the mach thread port name as the os thread identifier on OS X. We get this value by calling mach_thread_self(), but we (I) didn't realize that this "port" resource is reference counted and mach_thread_self() increases the reference count, but we never call mach_port_deallocate() to decrease the reference count. This leads to a resource leak and eventually mach_thread_self() will return 0 to indicate that we are out of ports. Running out of ports causes the pthreads implementation (which is built on top of mach) to spin forever in some calls (most notably in this case pthread_kill()).
>
> One way to fix this is to make sure we call mach_port_deallocate() for each call to mach_thread_self(). However, this adds extra complexity to the code and also makes it slower. Another solution is to ask pthreads for the mach port name that it already has. Pthreads provides the function pthread_mach_thread_np() for this purpose. In this case there is no need to deallocate the port since pthread_mach_thread_np() will not increase the reference count (and pthreads will call deallocate on the port once the thread terminates).
>
> This fix has been verified by seeing that the number of ports the process has allocated does not increase in Activity Monitor (or top). It has also passed JPRT testing on all platforms.
>
> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
> (there is not publicly visible bug for this)
>
> Thanks,
> /Staffan


From gerard.ziemski at oracle.com  Mon Aug 19 09:11:01 2013
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Mon, 19 Aug 2013 11:11:01 -0500
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
Message-ID: <52124395.2000709@oracle.com>

hi Staffan,

A search on the topic of Mac thread id reveals that pretty much everyone 
(including Apple itself) uses pthread_mach_thread_np() for thread id, so 
it looks like you're correct to use it.

I do have some more quick feedback/questions:

1. Could the "just checking" string in guarantee() be set to something 
more informative, like "thread id doesn't exist"?

2. Why are we using the the "::" C++ name space before mach/pthread C 
APIs calls? I understand that you might be just following the existing 
pattern in the file, I'm just wondering if you, or anyone knows why.

3. Also not directly related to your fix, but do you know why we need 
both "set_thread_id" and "set_unique_thread_id"


cheers


On 8/19/2013 4:08 AM, Staffan Larsen wrote:
> We are using the mach thread port name as the os thread identifier on OS X. We get this value by calling mach_thread_self(), but we (I) didn't realize that this "port" resource is reference counted and mach_thread_self() increases the reference count, but we never call mach_port_deallocate() to decrease the reference count. This leads to a resource leak and eventually mach_thread_self() will return 0 to indicate that we are out of ports. Running out of ports causes the pthreads implementation (which is built on top of mach) to spin forever in some calls (most notably in this case pthread_kill()).
>
> One way to fix this is to make sure we call mach_port_deallocate() for each call to mach_thread_self(). However, this adds extra complexity to the code and also makes it slower. Another solution is to ask pthreads for the mach port name that it already has. Pthreads provides the function pthread_mach_thread_np() for this purpose. In this case there is no need to deallocate the port since pthread_mach_thread_np() will not increase the reference count (and pthreads will call deallocate on the port once the thread terminates).
>
> This fix has been verified by seeing that the number of ports the process has allocated does not increase in Activity Monitor (or top). It has also passed JPRT testing on all platforms.
>
> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
> (there is not publicly visible bug for this)
>
> Thanks,
> /Staffan


From staffan.larsen at oracle.com  Mon Aug 19 10:14:26 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 19 Aug 2013 19:14:26 +0200
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <52123AB4.3090609@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
	<52123AB4.3090609@oracle.com>
Message-ID: <C0882F81-A8AC-4D05-A0CC-C2B31D068322@oracle.com>

I thought that was the recommended way of calling OS functions. We seem to have both styles, though.

/Staffan

On 19 aug 2013, at 17:33, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:

> hi Staffan,
> 
> Why are we using the the "::" C++ name space before mach/pthread C APIs calls?
> 
> 
> cheers
> 
> On 8/19/2013 4:08 AM, Staffan Larsen wrote:
>> We are using the mach thread port name as the os thread identifier on OS X. We get this value by calling mach_thread_self(), but we (I) didn't realize that this "port" resource is reference counted and mach_thread_self() increases the reference count, but we never call mach_port_deallocate() to decrease the reference count. This leads to a resource leak and eventually mach_thread_self() will return 0 to indicate that we are out of ports. Running out of ports causes the pthreads implementation (which is built on top of mach) to spin forever in some calls (most notably in this case pthread_kill()).
>> 
>> One way to fix this is to make sure we call mach_port_deallocate() for each call to mach_thread_self(). However, this adds extra complexity to the code and also makes it slower. Another solution is to ask pthreads for the mach port name that it already has. Pthreads provides the function pthread_mach_thread_np() for this purpose. In this case there is no need to deallocate the port since pthread_mach_thread_np() will not increase the reference count (and pthreads will call deallocate on the port once the thread terminates).
>> 
>> This fix has been verified by seeing that the number of ports the process has allocated does not increase in Activity Monitor (or top). It has also passed JPRT testing on all platforms.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
>> (there is not publicly visible bug for this)
>> 
>> Thanks,
>> /Staffan
> 


From staffan.larsen at oracle.com  Mon Aug 19 10:18:06 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 19 Aug 2013 19:18:06 +0200
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <52124395.2000709@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
	<52124395.2000709@oracle.com>
Message-ID: <2759143D-222B-486A-9854-356997E57899@oracle.com>


On 19 aug 2013, at 18:11, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:

> hi Staffan,
> 
> A search on the topic of Mac thread id reveals that pretty much everyone (including Apple itself) uses pthread_mach_thread_np() for thread id, so it looks like you're correct to use it.
> 
> I do have some more quick feedback/questions:
> 
> 1. Could the "just checking" string in guarantee() be set to something more informative, like "thread id doesn't exist"?

I'll fix that.

> 2. Why are we using the the "::" C++ name space before mach/pthread C APIs calls? I understand that you might be just following the existing pattern in the file, I'm just wondering if you, or anyone knows why.
> 
> 3. Also not directly related to your fix, but do you know why we need both "set_thread_id" and "set_unique_thread_id"

The "unique" (not a good name) id is used by SA when matching threads. See JDK-8006423 for a longer discussion. The reason we don't want to use the "unique" id as thread_id is that it is a 64 bit number.

Thanks,
/Staffan

> 
> 
> cheers
> 
> 
> On 8/19/2013 4:08 AM, Staffan Larsen wrote:
>> We are using the mach thread port name as the os thread identifier on OS X. We get this value by calling mach_thread_self(), but we (I) didn't realize that this "port" resource is reference counted and mach_thread_self() increases the reference count, but we never call mach_port_deallocate() to decrease the reference count. This leads to a resource leak and eventually mach_thread_self() will return 0 to indicate that we are out of ports. Running out of ports causes the pthreads implementation (which is built on top of mach) to spin forever in some calls (most notably in this case pthread_kill()).
>> 
>> One way to fix this is to make sure we call mach_port_deallocate() for each call to mach_thread_self(). However, this adds extra complexity to the code and also makes it slower. Another solution is to ask pthreads for the mach port name that it already has. Pthreads provides the function pthread_mach_thread_np() for this purpose. In this case there is no need to deallocate the port since pthread_mach_thread_np() will not increase the reference count (and pthreads will call deallocate on the port once the thread terminates).
>> 
>> This fix has been verified by seeing that the number of ports the process has allocated does not increase in Activity Monitor (or top). It has also passed JPRT testing on all platforms.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
>> (there is not publicly visible bug for this)
>> 
>> Thanks,
>> /Staffan
> 


From lois.foltan at oracle.com  Mon Aug 19 10:40:03 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 19 Aug 2013 13:40:03 -0400
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <520CF52B.6050000@oracle.com>
References: <520CF52B.6050000@oracle.com>
Message-ID: <52125873.1070407@oracle.com>

Hi Yumin,

Looks good, a couple of review comments:

    - I like that you pulled out the number 10 into the EXTRACHARLEN 
macro, can you explain the assigned value of 20?

    - Is -Xloggc:stdout or -Xloggc:stderr allowed?  If yes, can 
-XX:+UseGCLogFileRotation be specified at the same time?

    - Also, I am concerned about the introduction of temporary files 
called "<file_name>.<number>.current", why is this necessary?
      This scheme carries with it the additional potential for failure 
points like the ones you added checks for in 
rotatingFileStream::rotate_log().
      During error conditions, spurious <file_name>.<number>.current 
files could be left around that have no meaning or context.

    - You've added checks in rotatingFileStream::rotate_log() for if a 
pre-existing file can not be removed or if the current
       <file_name>.<number>.current can not be renamed.  If either of 
those errors occur, a warning is issued but then the log
       rotation proceeds.  So there could be a loss of -Xloggc 
information in the concurrent progression of rotating files.
       Would a better approach be to not close the existing log file in 
the rotation, proceed to determine if the next log file can be opened
       and if not, issue a warning, turn of UseGCLogFileRotation and 
continue to concatenate -Xloggc info into current file?

Thanks,
Lois


On 8/15/2013 11:35 AM, Yumin Qi wrote:
> Hi,
>
>   Can I have your review for this small changes?
> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>
>    This is for a enhancement to add head/tail message to the logging 
> files to assist reading GC output.
>    1. modified prompt message if invalid arguments used for log rotating;
>    2. add time and file name message to log file head/tail.
>    3. for easily identify which log file is current, use file name 
> like <filename>.n.current, after it reaches maximum size, rename it to 
> <filename>.n
>         On Windows, there is no F_OK (existing test) definition, F_OK 
> is defined as "0" and for _access of VC++, it just describes:
>
> modevalue
>
> 	
>
> Checks file for
>
> 00
>
> 	
>
> Existence only
>
> 02
>
> 	
>
> Write-only
>
> 04
>
> 	
>
> Read-only
>
> 06
>
> 	
>
> Read and write
>
>
> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
> The definition are consistent with unistd.h.
>
>     Test: JPRT and jtreg.
>
>    Thanks
>    Yumin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130819/9479a089/attachment-0001.html 

From yumin.qi at oracle.com  Mon Aug 19 10:48:16 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 19 Aug 2013 10:48:16 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <10E39A148B301E4982FD13F7FCB3B5CE0A3FB5D4@MISOUT7MSGUSR9C.ITServices.sbc.com>
References: <520CF52B.6050000@oracle.com> <52116800.3040901@lab.ntt.co.jp>
	<10E39A148B301E4982FD13F7FCB3B5CE0A3FB5D4@MISOUT7MSGUSR9C.ITServices.sbc.com>
Message-ID: <52125A60.4050906@oracle.com>

Scott and Yasumasa,

   Thanks for your information for bug 6950794.

   According to my current implementation, it is easy to identify which 
file is the current log ---- it ends up with .current appendix. At app 
exit, it did not renamed to other name so still is the last and latest 
log file.

   I will make modification based on current implementation to cover 
suggestions mentioned  in bug 6950794.
   This will be only targeted to if gc log file rotations successfully set:
   Log file name will be <filename>-pid%p-YYYY-MM-DD_HH-MM-SS.%i  which 
p is pid and i be one of 0, ...., n-1. I am not planning to parse 
command line to get those info since they are available internally. Hope 
this will solve the problems mentioned in bug 6950794.

   So the rotation will be:
    1) File name,  like mentioned above, example: 
gc.log-pid1234-2013-08-19_08-20-00.1 with
          -Xloggc:gc.log -XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=5  -XX:GCLogFileSize=1M
         Time stamp is the start of first rotation file created, and all 
rotation files share the same time stamp in file name.
    2) Time stamp of each rotation begings still logged when it is 
started, finished.
    3) For rotation in same file, the file name will be 
<filename>-pid%p-YYYY-MM-DD_HH-MM-SS

   Let me know what you think.

Thanks
Yumin

On 8/19/2013 8:07 AM, STIRLING, SCOTT wrote:
> For hosting large e-comm sites with dozens to hundreds of JVMs, where we always have GC logging enabled, the advent of GC log rotation features in the JVM was a nice surprise and I started using it immediately on a major new e-comm site (with Oracle ATG and Weblogic on Sun 1.6-latest JDK and RHEL). But as the file naming and rotation work now, when you stop and then restart a JVM with GC log rotation enabled, it overwrites the last un-rotated log file. That's not usually what we want. We like logs to have the timestamp or datestamp encoded in the file name for scripting, for future reference when logs are on a laptop for analysis with visualization tools (more important these days as GC logs for new garbage collectors get uglier and uglier), etc.
>
> It's possible to parameterize the log file name in scripts before it is passed to the JVM, but that's been do-able for years. And if you take a product such as Oracle Weblogic, it has a versionable, auto-deployed, centrally manageable config.xml, which we like to use as much as possible for, e.g., all the JVM args for all the JVMs in the domain. There's no facility for parameterized variables in config.xml. So you have to, again, do stuff in the launch script, which is more stuff to maintain, and so on.
>
> I'm willing to compile the patch for 6950794 and let you know if it compiles on Windows 7, 64 bit. I'm just a list observer but I can build it.
>
> Scott Stirling
> AT&T, Boston
>
> -----Original Message-----
> From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Yasumasa Suenaga
> Sent: Sunday, August 18, 2013 8:34 PM
> To: Yumin Qi
> Cc: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR: 7164841: Improvements to the GC log file rotation
>
> Hi Yumin,
>
> I've posted a RFE and patch for adding timestamp, PID, etc to log filename.
>
> JDK-6950794 : Make the GC log file name parameterized
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6950794
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html
>
> Your patch writes timestamp into logfile.
> Howeverm, in production system, we may want to check log generation through
> log filename. (e.g. ls command at Linux)
>
> Could you check my patch?
>
>
> Thanks,
>
> Yasumasa
>
> On 2013/08/16 0:35, Yumin Qi wrote:
>> Hi,
>>
>>     Can I have your review for this small changes?
>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>
>>      This is for a enhancement to add head/tail message to the logging files to assist reading GC output.
>>      1. modified prompt message if invalid arguments used for log rotating;
>>      2. add time and file name message to log file head/tail.
>>      3. for easily identify which log file is current, use file name like <filename>.n.current, after it reaches maximum size, rename it to <filename>.n
>>           On Windows, there is no F_OK (existing test) definition, F_OK is defined as "0" and for _access of VC++, it just describes:
>>
>> modevalue
>>
>> 	
>>
>> Checks file for
>>
>> 00
>>
>> 	
>>
>> Existence only
>>
>> 02
>>
>> 	
>>
>> Write-only
>>
>> 04
>>
>> 	
>>
>> Read-only
>>
>> 06
>>
>> 	
>>
>> Read and write
>>
>>
>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>> The definition are consistent with unistd.h.
>>
>>       Test: JPRT and jtreg.
>>
>>      Thanks
>>      Yumin


From mikhailo.seledtsov at oracle.com  Mon Aug 19 10:50:07 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Mon, 19 Aug 2013 13:50:07 -0400
Subject: RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh failed
	- round 2
Message-ID: <52125ACF.9050803@oracle.com>

This is a round 2 review for this fix.
Please review.

Original review request (dated 16-July-2013) with the same subject was:
"
Please review this test fix. The change is a fix for the original bug, 
plus an update to the test condition to reflect new JVM behavior and a 
rewrite of an sh script test in Java.
JBS: https://jbs.oracle.com/bugs/browse/JDK-8016029
(Old) Webrev: http://cr.openjdk.java.net/~mseledtsov/6878713/webrev.00/ 
<http://cr.openjdk.java.net/%7Emseledtsov/6878713/webrev.00/>
"


Change since last round of review:
     JVM run-time technical leadership has made a decision to keep the 
testcase.jar until a long-term solution is in place for handling "Java 
assembler"-based and byte-code-based test cases.

Here is the updated webrev and comments:
     Webrev: http://cr.openjdk.java.net/~mseledtsov/8016029/webrev.01/ 
<http://cr.openjdk.java.net/%7Emseledtsov/8016029/webrev.01/>
     Testing: JPRT run for this test 
(2013-08-19-154813.mseledtsov.bugFixing01-hotspot-rt)

Here are original notes:
- the original behavior of the VM in this test case has changed, and the 
expected error message has changed as well. There is an extensive amount 
of information about this in the original bug, posted by Dan. The change 
was introduced in change-set: 4876:f75faf51e8c4 by Harold. Checking for 
the old expected messages has been removed from the test. This change is 
for JDK8 and forward, and no back-ports planned.

- the flag -XX:+IgnoreUnrecognizedVMOptions has been removed to avoid 
masking a potential problem. If VM drops support for any of XX flags 
used in this test, it is better to know about it right away rather than 
mask it and silently pass/ignore.

- the flag -XX:+PrintCommandLineFlags has been removed; if this 
information is desired, IMO it should be triggered either by a verbose 
mode of JTREG tools, or by hand, not by individual test(s).

Round 2 notes:
- the shell script has been replaced by Java

- test has been moved to a new location, moving away from using bug 
numbers to using functional categories for test sub-folders


Misha

From calvin.cheung at oracle.com  Mon Aug 19 11:01:53 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Mon, 19 Aug 2013 11:01:53 -0700
Subject: Request for Review 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh
	fails on 64-bit solaris
In-Reply-To: <5212231A.7070704@oracle.com>
References: <5203F024.9040006@oracle.com> <5212231A.7070704@oracle.com>
Message-ID: <52125D91.5080807@oracle.com>

Hi Harold,

The fix looks good to me. (not a Reviewer)
A minor typo in line #27:
     -xcheck:jni   -->  -Xcheck:jni

Calvin

On 8/19/2013 6:52 AM, harold seigel wrote:
> Hi,
>
> I'm resending this RFR because I did not get any reviewers the first 
> time.  If you have chance, please take a look.
>
> Thanks, Harold
>
> On 8/8/2013 3:23 PM, harold seigel wrote:
>> Hi,
>>
>> Please review this change to fix bug 7121403.  The test was rewritten 
>> in Java and modified to properly determine when it is running on 
>> 64-bit Solaris.
>>
>> The fix was tested by running the new test on 32-bit Linux, Solaris 
>> Sparc, Solaris X86, and 64-bit Linux.
>>
>> webrev: http://cr.openjdk.java.net/~hseigel/bug_7121403/ 
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_7121403/>
>>
>> bug: http://bugs.sun.com/view_bug.do?bug_id=7121403
>>
>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-7121403
>>
>> Thanks! Harold
>


From harold.seigel at oracle.com  Mon Aug 19 11:12:42 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Mon, 19 Aug 2013 14:12:42 -0400
Subject: Request for Review 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh
	fails on 64-bit solaris
In-Reply-To: <52125D91.5080807@oracle.com>
References: <5203F024.9040006@oracle.com> <5212231A.7070704@oracle.com>
	<52125D91.5080807@oracle.com>
Message-ID: <5212601A.3020302@oracle.com>

Thanks Calvin!  I'll fix the typo.

Harold

On 8/19/2013 2:01 PM, Calvin Cheung wrote:
> Hi Harold,
>
> The fix looks good to me. (not a Reviewer)
> A minor typo in line #27:
>     -xcheck:jni   -->  -Xcheck:jni
>
> Calvin
>
> On 8/19/2013 6:52 AM, harold seigel wrote:
>> Hi,
>>
>> I'm resending this RFR because I did not get any reviewers the first 
>> time.  If you have chance, please take a look.
>>
>> Thanks, Harold
>>
>> On 8/8/2013 3:23 PM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this change to fix bug 7121403.  The test was 
>>> rewritten in Java and modified to properly determine when it is 
>>> running on 64-bit Solaris.
>>>
>>> The fix was tested by running the new test on 32-bit Linux, Solaris 
>>> Sparc, Solaris X86, and 64-bit Linux.
>>>
>>> webrev: http://cr.openjdk.java.net/~hseigel/bug_7121403/ 
>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_7121403/>
>>>
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7121403
>>>
>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-7121403
>>>
>>> Thanks! Harold
>>
>


From david.r.chase at oracle.com  Mon Aug 19 11:13:15 2013
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 19 Aug 2013 14:13:15 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <52119939.50205@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
	<94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
	<F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>
	<52119939.50205@oracle.com>
Message-ID: <2415DA74-C2C1-4B34-8598-9A0072FA7BA9@oracle.com>

New version, with Christian's and John's fixes (and limited use of err_msg_res):

http://cr.openjdk.java.net/~drchase/8014013/webrev.03/

retested (jtreg) on Mac against hotspot/test/compiler, jdk/test/{jdk,java/util}

David


On 2013-08-19, at 12:04 AM, David Holmes <david.holmes at oracle.com> wrote:

> On 19/08/2013 8:24 AM, David Chase wrote:
>> A question about err_msg_res -- should that generally be used in place of err_msg,
>> or only in certain source directories, and if so, which ones?
> 
> I can't answer that but be aware that there is an issue with using err_msg_res as it is unclear as to whom has responsibility for ensuring there is a ResourceMark on the stack. There's an open bug on that - 8022187.
> 
> David
> 
>> On 2013-08-17, at 1:41 AM, John Rose <john.r.rose at oracle.com> wrote:
>> 
>>> On Aug 16, 2013, at 1:05 PM, David Chase <david.r.chase at oracle.com> wrote:
>>> 
>>>> How does this look?
>>>> 
>>>> void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
>>>>  if (_cp.is_null() || field_holder() != ik) {
>>>>    _cp = constantPoolHandle(Thread::current(), ik->constants());
>>>>    // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
>>>>    assert(field_holder() == ik, "must be already initialized to this class");
>>> 
>>> Good.
>>> 
>>> As a side note, this bit of code (and many others) assume that there is a 1-1 correspondence between constant pools and instance klasses.
>>> 
>>> I hope we can change this some day; the tracking bug is http://bugs.sun.com/view_bug.do?bug_id=6711913
>>> 
>>> ? John
>> 


From mikhailo.seledtsov at oracle.com  Mon Aug 19 11:44:11 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Mon, 19 Aug 2013 14:44:11 -0400
Subject: Request for Review 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh
	fails on 64-bit solaris
In-Reply-To: <5212601A.3020302@oracle.com>
References: <5203F024.9040006@oracle.com> <5212231A.7070704@oracle.com>
	<52125D91.5080807@oracle.com> <5212601A.3020302@oracle.com>
Message-ID: <5212677B.704@oracle.com>

Hi Harold,

  Your change looks good, than you for re-writing sh in Java.

  One minor comment:

import java.io.File;  - looks like this import is no longer in use
No need to re-post the change.

Misha


On 8/19/2013 2:12 PM, harold seigel wrote:
> Thanks Calvin!  I'll fix the typo.
>
> Harold
>
> On 8/19/2013 2:01 PM, Calvin Cheung wrote:
>> Hi Harold,
>>
>> The fix looks good to me. (not a Reviewer)
>> A minor typo in line #27:
>>     -xcheck:jni   -->  -Xcheck:jni
>>
>> Calvin
>>
>> On 8/19/2013 6:52 AM, harold seigel wrote:
>>> Hi,
>>>
>>> I'm resending this RFR because I did not get any reviewers the first 
>>> time.  If you have chance, please take a look.
>>>
>>> Thanks, Harold
>>>
>>> On 8/8/2013 3:23 PM, harold seigel wrote:
>>>> Hi,
>>>>
>>>> Please review this change to fix bug 7121403.  The test was 
>>>> rewritten in Java and modified to properly determine when it is 
>>>> running on 64-bit Solaris.
>>>>
>>>> The fix was tested by running the new test on 32-bit Linux, Solaris 
>>>> Sparc, Solaris X86, and 64-bit Linux.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~hseigel/bug_7121403/ 
>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_7121403/>
>>>>
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7121403
>>>>
>>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-7121403
>>>>
>>>> Thanks! Harold
>>>
>>
>


From yumin.qi at oracle.com  Mon Aug 19 13:41:05 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 19 Aug 2013 13:41:05 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <52125873.1070407@oracle.com>
References: <520CF52B.6050000@oracle.com> <52125873.1070407@oracle.com>
Message-ID: <521282E1.9080403@oracle.com>

Thanks Lois for the review, see embedded.

On 8/19/2013 10:40 AM, Lois Foltan wrote:
> Hi Yumin,
>
> Looks good, a couple of review comments:
>
>    - I like that you pulled out the number 10 into the EXTRACHARLEN 
> macro, can you explain the assigned value of 20?
>
jio_snprintf(_file_name, strlen(file_name) + EXTRACHARLEN, "%s.%d.current", file_name, _cur_file_num);
This is for extra space needed to print chars after file_name, 20 seems enough.

>    - Is -Xloggc:stdout or -Xloggc:stderr allowed?  If yes, can 
> -XX:+UseGCLogFileRotation be specified at the same time?
>
stdout and stderr is a number, 1 and 2 defined for io.h not stdio.h, so 
they are perfectly filenames after loggc:, the file names will be 
"stdout/err".
>    - Also, I am concerned about the introduction of temporary files 
> called "<file_name>.<number>.current", why is this necessary?
>      This scheme carries with it the additional potential for failure 
> points like the ones you added checks for in 
> rotatingFileStream::rotate_log().
>      During error conditions, spurious <file_name>.<number>.current 
> files could be left around that have no meaning or context.
>
The rotation itself has potential problems if the dir modified by owner 
for access priorities. I think if cannot open the next rotation file, 
the best way will be issue warning and stop log file rotation, or just 
like you said, just rotate in the current file. This part is tricky and 
just like the next question. If we don't have permission to access, 
remove and rename files, that means we have no permissions to operate 
files in current directory so the rotation is not possible. I will try 
more tests about this part.

Thanks
Yumin
>    - You've added checks in rotatingFileStream::rotate_log() for if a 
> pre-existing file can not be removed or if the current
>       <file_name>.<number>.current can not be renamed.  If either of 
> those errors occur, a warning is issued but then the log
>       rotation proceeds.  So there could be a loss of -Xloggc 
> information in the concurrent progression of rotating files.
>       Would a better approach be to not close the existing log file in 
> the rotation, proceed to determine if the next log file can be opened
>       and if not, issue a warning, turn of UseGCLogFileRotation and 
> continue to concatenate -Xloggc info into current file?
>
> Thanks,
> Lois
>
>
> On 8/15/2013 11:35 AM, Yumin Qi wrote:
>> Hi,
>>
>>   Can I have your review for this small changes?
>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>
>>    This is for a enhancement to add head/tail message to the logging 
>> files to assist reading GC output.
>>    1. modified prompt message if invalid arguments used for log rotating;
>>    2. add time and file name message to log file head/tail.
>>    3. for easily identify which log file is current, use file name 
>> like <filename>.n.current, after it reaches maximum size, rename it 
>> to <filename>.n
>>         On Windows, there is no F_OK (existing test) definition, F_OK 
>> is defined as "0" and for _access of VC++, it just describes:
>>
>> modevalue
>>
>> 	
>>
>> Checks file for
>>
>> 00
>>
>> 	
>>
>> Existence only
>>
>> 02
>>
>> 	
>>
>> Write-only
>>
>> 04
>>
>> 	
>>
>> Read-only
>>
>> 06
>>
>> 	
>>
>> Read and write
>>
>>
>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>> The definition are consistent with unistd.h.
>>
>>     Test: JPRT and jtreg.
>>
>>    Thanks
>>    Yumin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130819/74e514b9/attachment.html 

From christian.thalinger at oracle.com  Mon Aug 19 15:15:43 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 19 Aug 2013 15:15:43 -0700
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <2415DA74-C2C1-4B34-8598-9A0072FA7BA9@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
	<94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
	<F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>
	<52119939.50205@oracle.com>
	<2415DA74-C2C1-4B34-8598-9A0072FA7BA9@oracle.com>
Message-ID: <925B8B0B-E7A9-4934-B8F8-FAABB6492B01@oracle.com>

Looks good.  -- Chris

On Aug 19, 2013, at 11:13 AM, David Chase <david.r.chase at oracle.com> wrote:

> New version, with Christian's and John's fixes (and limited use of err_msg_res):
> 
> http://cr.openjdk.java.net/~drchase/8014013/webrev.03/
> 
> retested (jtreg) on Mac against hotspot/test/compiler, jdk/test/{jdk,java/util}
> 
> David
> 
> 
> On 2013-08-19, at 12:04 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
>> On 19/08/2013 8:24 AM, David Chase wrote:
>>> A question about err_msg_res -- should that generally be used in place of err_msg,
>>> or only in certain source directories, and if so, which ones?
>> 
>> I can't answer that but be aware that there is an issue with using err_msg_res as it is unclear as to whom has responsibility for ensuring there is a ResourceMark on the stack. There's an open bug on that - 8022187.
>> 
>> David
>> 
>>> On 2013-08-17, at 1:41 AM, John Rose <john.r.rose at oracle.com> wrote:
>>> 
>>>> On Aug 16, 2013, at 1:05 PM, David Chase <david.r.chase at oracle.com> wrote:
>>>> 
>>>>> How does this look?
>>>>> 
>>>>> void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
>>>>> if (_cp.is_null() || field_holder() != ik) {
>>>>>   _cp = constantPoolHandle(Thread::current(), ik->constants());
>>>>>   // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
>>>>>   assert(field_holder() == ik, "must be already initialized to this class");
>>>> 
>>>> Good.
>>>> 
>>>> As a side note, this bit of code (and many others) assume that there is a 1-1 correspondence between constant pools and instance klasses.
>>>> 
>>>> I hope we can change this some day; the tracking bug is http://bugs.sun.com/view_bug.do?bug_id=6711913
>>>> 
>>>> ? John
>>> 
> 


From ysr1729 at gmail.com  Mon Aug 19 15:31:25 2013
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Mon, 19 Aug 2013 15:31:25 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <520CF52B.6050000@oracle.com>
References: <520CF52B.6050000@oracle.com>
Message-ID: <CABzyjymvDXxLC1nhk4MLZqi07tsP07gn_DdupHkdNqKThpa+dg@mail.gmail.com>

Hi Yumin --

Somewhat orthogonal to the discussion at hand, and certainly not a code
review/discussion (so i
apologize for injecting this into $SUBJ) but I wanted to say that log
rotation is definitely a useful capability in the field.

Have you folks perhaps considered two possible enhancements:
(1) rotate logs at a frequency and time specified. (For example, on a
daily, weekly or monthly basis.)
(2) rotate logs asynchronously upon request. (say via a suitable bean.)

If (1) can be simulated by existing means I am all ears.

thanks!
-- ramki



On Thu, Aug 15, 2013 at 8:35 AM, Yumin Qi <yumin.qi at oracle.com> wrote:

>  Hi,
>
>   Can I have your review for this small changes?
>   http://cr.openjdk.java.net/~minqi/7164841/webrev00/
>
>    This is for a enhancement to add head/tail message to the logging files
> to assist reading GC output.
>    1. modified prompt message if invalid arguments used for log rotating;
>    2. add time and file name message to log file head/tail.
>    3. for easily identify which log file is current, use file name like
> <filename>.n.current, after it reaches maximum size, rename it to
> <filename>.n
>         On Windows, there is no F_OK (existing test) definition, F_OK is
> defined as "0" and for _access of VC++, it just describes:
>
>
> mode value
>
> Checks file for
>
> 00
>
> Existence only
>
> 02
>
> Write-only
>
> 04
>
> Read-only
>
> 06
>
> Read and write
>
> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
> The definition are consistent with unistd.h.
>
>     Test: JPRT and jtreg.
>
>    Thanks
>    Yumin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130819/386dfe93/attachment-0001.html 

From david.r.chase at oracle.com  Mon Aug 19 15:46:55 2013
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 19 Aug 2013 18:46:55 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <925B8B0B-E7A9-4934-B8F8-FAABB6492B01@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
	<94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
	<F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>
	<52119939.50205@oracle.com>
	<2415DA74-C2C1-4B34-8598-9A0072FA7BA9@oracle.com>
	<925B8B0B-E7A9-4934-B8F8-FAABB6492B01@oracle.com>
Message-ID: <727C0BA7-6E86-4FBB-A1CB-8E7670A27214@oracle.com>

Karen Kinnear would like me to study, carefully, the wrong answer that occur in one of the default methods tests.
Apparently this is an instance of a test where the wrong answers are still interesting -- this patch fails less, but
in a few cases it fails differently.

David

On 2013-08-19, at 6:15 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> Looks good.  -- Chris
> 
> On Aug 19, 2013, at 11:13 AM, David Chase <david.r.chase at oracle.com> wrote:
> 
>> New version, with Christian's and John's fixes (and limited use of err_msg_res):
>> 
>> http://cr.openjdk.java.net/~drchase/8014013/webrev.03/
>> 
>> retested (jtreg) on Mac against hotspot/test/compiler, jdk/test/{jdk,java/util}
>> 
>> David
>> 
>> 
>> On 2013-08-19, at 12:04 AM, David Holmes <david.holmes at oracle.com> wrote:
>> 
>>> On 19/08/2013 8:24 AM, David Chase wrote:
>>>> A question about err_msg_res -- should that generally be used in place of err_msg,
>>>> or only in certain source directories, and if so, which ones?
>>> 
>>> I can't answer that but be aware that there is an issue with using err_msg_res as it is unclear as to whom has responsibility for ensuring there is a ResourceMark on the stack. There's an open bug on that - 8022187.
>>> 
>>> David
>>> 
>>>> On 2013-08-17, at 1:41 AM, John Rose <john.r.rose at oracle.com> wrote:
>>>> 
>>>>> On Aug 16, 2013, at 1:05 PM, David Chase <david.r.chase at oracle.com> wrote:
>>>>> 
>>>>>> How does this look?
>>>>>> 
>>>>>> void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
>>>>>> if (_cp.is_null() || field_holder() != ik) {
>>>>>>  _cp = constantPoolHandle(Thread::current(), ik->constants());
>>>>>>  // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
>>>>>>  assert(field_holder() == ik, "must be already initialized to this class");
>>>>> 
>>>>> Good.
>>>>> 
>>>>> As a side note, this bit of code (and many others) assume that there is a 1-1 correspondence between constant pools and instance klasses.
>>>>> 
>>>>> I hope we can change this some day; the tracking bug is http://bugs.sun.com/view_bug.do?bug_id=6711913
>>>>> 
>>>>> ? John
>>>> 
>> 
> 


From yumin.qi at oracle.com  Mon Aug 19 15:52:30 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 19 Aug 2013 15:52:30 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <CABzyjymvDXxLC1nhk4MLZqi07tsP07gn_DdupHkdNqKThpa+dg@mail.gmail.com>
References: <520CF52B.6050000@oracle.com>
	<CABzyjymvDXxLC1nhk4MLZqi07tsP07gn_DdupHkdNqKThpa+dg@mail.gmail.com>
Message-ID: <5212A1AE.1010005@oracle.com>

Thanks, Ramki

On 8/19/2013 3:31 PM, Srinivas Ramakrishna wrote:
>
> Hi Yumin --
>
> Somewhat orthogonal to the discussion at hand, and certainly not a 
> code review/discussion (so i
> apologize for injecting this into $SUBJ) but I wanted to say that log 
> rotation is definitely a useful capability in the field.
>
> Have you folks perhaps considered two possible enhancements:
> (1) rotate logs at a frequency and time specified. (For example, on a 
> daily, weekly or monthly basis.)
No such consideration at present.  This  needs an option for specifying 
the frequency.
> (2) rotate logs asynchronously upon request. (say via a suitable bean.)
>
I can file a bug for serviceability to have this function together with 
(1) through jmx or jmc.

Thanks
Yumin
> If (1) can be simulated by existing means I am all ears.
>
> thanks!
> -- ramki
>
>
>
> On Thu, Aug 15, 2013 at 8:35 AM, Yumin Qi <yumin.qi at oracle.com 
> <mailto:yumin.qi at oracle.com>> wrote:
>
>     Hi,
>
>       Can I have your review for this small changes?
>     http://cr.openjdk.java.net/~minqi/7164841/webrev00/
>     <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>
>        This is for a enhancement to add head/tail message to the
>     logging files to assist reading GC output.
>        1. modified prompt message if invalid arguments used for log
>     rotating;
>        2. add time and file name message to log file head/tail.
>        3. for easily identify which log file is current, use file name
>     like <filename>.n.current, after it reaches maximum size, rename
>     it to <filename>.n
>             On Windows, there is no F_OK (existing test) definition,
>     F_OK is defined as "0" and for _access of VC++, it just describes:
>
>     modevalue
>
>     	
>
>     Checks file for
>
>     00
>
>     	
>
>     Existence only
>
>     02
>
>     	
>
>     Write-only
>
>     04
>
>     	
>
>     Read-only
>
>     06
>
>     	
>
>     Read and write
>
>
>     http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>     The definition are consistent with unistd.h.
>
>         Test: JPRT and jtreg.
>
>        Thanks
>        Yumin
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130819/42076b17/attachment.html 

From suenaga.yasumasa at lab.ntt.co.jp  Mon Aug 19 16:48:43 2013
From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga)
Date: Tue, 20 Aug 2013 08:48:43 +0900
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <5212A1AE.1010005@oracle.com>
References: <520CF52B.6050000@oracle.com>
	<CABzyjymvDXxLC1nhk4MLZqi07tsP07gn_DdupHkdNqKThpa+dg@mail.gmail.com>
	<5212A1AE.1010005@oracle.com>
Message-ID: <5212AEDB.20007@lab.ntt.co.jp>

Hi all,

> I can file a bug for serviceability to have this function together with (1) through jmx or jmc.

I already filed as 7090324.
7090324: gclog rotation via external tool
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7090324

In last year, I tried to implement GC log rotation to jcmd.
I've attached that patch in this email.


Please check it.

Thanks,

Yasumasa


On 2013/08/20 7:52, Yumin Qi wrote:
> Thanks, Ramki
>
> On 8/19/2013 3:31 PM, Srinivas Ramakrishna wrote:
>>
>> Hi Yumin --
>>
>> Somewhat orthogonal to the discussion at hand, and certainly not a code review/discussion (so i
>> apologize for injecting this into $SUBJ) but I wanted to say that log rotation is definitely a useful capability in the field.
>>
>> Have you folks perhaps considered two possible enhancements:
>> (1) rotate logs at a frequency and time specified. (For example, on a daily, weekly or monthly basis.)
> No such consideration at present. This needs an option for specifying the frequency.
>> (2) rotate logs asynchronously upon request. (say via a suitable bean.)
>>
> I can file a bug for serviceability to have this function together with (1) through jmx or jmc.
>
> Thanks
> Yumin
>> If (1) can be simulated by existing means I am all ears.
>>
>> thanks!
>> -- ramki
>>
>>
>>
>> On Thu, Aug 15, 2013 at 8:35 AM, Yumin Qi <yumin.qi at oracle.com <mailto:yumin.qi at oracle.com>> wrote:
>>
>>     Hi,
>>
>>     Can I have your review for this small changes?
>>     http://cr.openjdk.java.net/~minqi/7164841/webrev00/ <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>
>>     This is for a enhancement to add head/tail message to the logging files to assist reading GC output.
>>     1. modified prompt message if invalid arguments used for log rotating;
>>     2. add time and file name message to log file head/tail.
>>     3. for easily identify which log file is current, use file name like <filename>.n.current, after it reaches maximum size, rename it to <filename>.n
>>     On Windows, there is no F_OK (existing test) definition, F_OK is defined as "0" and for _access of VC++, it just describes:
>>
>>     modevalue
>>
>>     	
>>
>>     Checks file for
>>
>>     00
>>
>>     	
>>
>>     Existence only
>>
>>     02
>>
>>     	
>>
>>     Write-only
>>
>>     04
>>
>>     	
>>
>>     Read-only
>>
>>     06
>>
>>     	
>>
>>     Read and write
>>
>>
>>     http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>     The definition are consistent with unistd.h.
>>
>>     Test: JPRT and jtreg.
>>
>>     Thanks
>>     Yumin
>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jcmd.patch
Type: text/x-patch
Size: 6667 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130820/8685c6d5/jcmd-0001.patch 

From suenaga.yasumasa at lab.ntt.co.jp  Mon Aug 19 16:57:53 2013
From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga)
Date: Tue, 20 Aug 2013 08:57:53 +0900
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <52125A60.4050906@oracle.com>
References: <520CF52B.6050000@oracle.com> <52116800.3040901@lab.ntt.co.jp>
	<10E39A148B301E4982FD13F7FCB3B5CE0A3FB5D4@MISOUT7MSGUSR9C.ITServices.sbc.com>
	<52125A60.4050906@oracle.com>
Message-ID: <5212B101.5000303@lab.ntt.co.jp>

Hi Yumin,

> Log file name will be <filename>-pid%p-YYYY-MM-DD_HH-MM-SS.%i which p is pid and i be one of 0, ...., n-1. I am not planning to parse command line to get those info since they are available internally. Hope this will solve the problems mentioned in bug 6950794.

I think this filename is too long. So I want to set filename format as 6950794.
If you run several JVMs as multi-tenancy, I think that PID will be very important.
But if not, PID is not so important.

Can you discuss for JVM options in this RFE ?


Thanks,

Yasumasa

On 2013/08/20 2:48, Yumin Qi wrote:
> Scott and Yasumasa,
>
> Thanks for your information for bug 6950794.
>
> According to my current implementation, it is easy to identify which file is the current log ---- it ends up with .current appendix. At app exit, it did not renamed to other name so still is the last and latest log file.
>
> I will make modification based on current implementation to cover suggestions mentioned in bug 6950794.
> This will be only targeted to if gc log file rotations successfully set:
> Log file name will be <filename>-pid%p-YYYY-MM-DD_HH-MM-SS.%i which p is pid and i be one of 0, ...., n-1. I am not planning to parse command line to get those info since they are available internally. Hope this will solve the problems mentioned in bug 6950794.
>
> So the rotation will be:
> 1) File name, like mentioned above, example: gc.log-pid1234-2013-08-19_08-20-00.1 with
> -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=1M
> Time stamp is the start of first rotation file created, and all rotation files share the same time stamp in file name.
> 2) Time stamp of each rotation begings still logged when it is started, finished.
> 3) For rotation in same file, the file name will be <filename>-pid%p-YYYY-MM-DD_HH-MM-SS
>
> Let me know what you think.
>
> Thanks
> Yumin
>
> On 8/19/2013 8:07 AM, STIRLING, SCOTT wrote:
>> For hosting large e-comm sites with dozens to hundreds of JVMs, where we always have GC logging enabled, the advent of GC log rotation features in the JVM was a nice surprise and I started using it immediately on a major new e-comm site (with Oracle ATG and Weblogic on Sun 1.6-latest JDK and RHEL). But as the file naming and rotation work now, when you stop and then restart a JVM with GC log rotation enabled, it overwrites the last un-rotated log file. That's not usually what we want. We like logs to have the timestamp or datestamp encoded in the file name for scripting, for future reference when logs are on a laptop for analysis with visualization tools (more important these days as GC logs for new garbage collectors get uglier and uglier), etc.
>>
>> It's possible to parameterize the log file name in scripts before it is passed to the JVM, but that's been do-able for years. And if you take a product such as Oracle Weblogic, it has a versionable, auto-deployed, centrally manageable config.xml, which we like to use as much as possible for, e.g., all the JVM args for all the JVMs in the domain. There's no facility for parameterized variables in config.xml. So you have to, again, do stuff in the launch script, which is more stuff to maintain, and so on.
>>
>> I'm willing to compile the patch for 6950794 and let you know if it compiles on Windows 7, 64 bit. I'm just a list observer but I can build it.
>>
>> Scott Stirling
>> AT&T, Boston
>>
>> -----Original Message-----
>> From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Yasumasa Suenaga
>> Sent: Sunday, August 18, 2013 8:34 PM
>> To: Yumin Qi
>> Cc: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR: 7164841: Improvements to the GC log file rotation
>>
>> Hi Yumin,
>>
>> I've posted a RFE and patch for adding timestamp, PID, etc to log filename.
>>
>> JDK-6950794 : Make the GC log file name parameterized
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6950794
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html
>>
>> Your patch writes timestamp into logfile.
>> Howeverm, in production system, we may want to check log generation through
>> log filename. (e.g. ls command at Linux)
>>
>> Could you check my patch?
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>> On 2013/08/16 0:35, Yumin Qi wrote:
>>> Hi,
>>>
>>> Can I have your review for this small changes?
>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>
>>> This is for a enhancement to add head/tail message to the logging files to assist reading GC output.
>>> 1. modified prompt message if invalid arguments used for log rotating;
>>> 2. add time and file name message to log file head/tail.
>>> 3. for easily identify which log file is current, use file name like <filename>.n.current, after it reaches maximum size, rename it to <filename>.n
>>> On Windows, there is no F_OK (existing test) definition, F_OK is defined as "0" and for _access of VC++, it just describes:
>>>
>>> modevalue
>>>
>>>
>>>
>>> Checks file for
>>>
>>> 00
>>>
>>>
>>>
>>> Existence only
>>>
>>> 02
>>>
>>>
>>>
>>> Write-only
>>>
>>> 04
>>>
>>>
>>>
>>> Read-only
>>>
>>> 06
>>>
>>>
>>>
>>> Read and write
>>>
>>>
>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>> The definition are consistent with unistd.h.
>>>
>>> Test: JPRT and jtreg.
>>>
>>> Thanks
>>> Yumin


From yumin.qi at oracle.com  Mon Aug 19 16:56:55 2013
From: yumin.qi at oracle.com (yumin.qi at oracle.com)
Date: Mon, 19 Aug 2013 23:56:55 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8023188: Unsafe volatile double store on
	bsd is broken
Message-ID: <20130819235657.BE7DF489C9@hg.openjdk.java.net>

Changeset: b1fd869e7df0
Author:    minqi
Date:      2013-08-19 09:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b1fd869e7df0

8023188: Unsafe volatile double store on bsd is broken
Reviewed-by: dcubed, dholmes
Contributed-by: yumin.qi at oracle.com

! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp


From suenaga.yasumasa at lab.ntt.co.jp  Mon Aug 19 17:02:37 2013
From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga)
Date: Tue, 20 Aug 2013 09:02:37 +0900
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <10E39A148B301E4982FD13F7FCB3B5CE0A3FB5D4@MISOUT7MSGUSR9C.ITServices.sbc.com>
References: <520CF52B.6050000@oracle.com> <52116800.3040901@lab.ntt.co.jp>
	<10E39A148B301E4982FD13F7FCB3B5CE0A3FB5D4@MISOUT7MSGUSR9C.ITServices.sbc.com>
Message-ID: <5212B21D.40602@lab.ntt.co.jp>

Hi Scott,

> I'm willing to compile the patch for 6950794 and let you know if it compiles on Windows 7, 64 bit. I'm just a list observer but I can build it.

Do you want to build JDK for Linux (RHEL) ? If so, you have to build JDK on Linux.
Please apply my patch for your OpenJDK source tree and read "README-builds.html" in it.

http://hg.openjdk.java.net/build-infra/jdk7/file/tip/README-builds.html


Thanks,

Yasumasa

On 2013/08/20 0:07, STIRLING, SCOTT wrote:
> For hosting large e-comm sites with dozens to hundreds of JVMs, where we always have GC logging enabled, the advent of GC log rotation features in the JVM was a nice surprise and I started using it immediately on a major new e-comm site (with Oracle ATG and Weblogic on Sun 1.6-latest JDK and RHEL). But as the file naming and rotation work now, when you stop and then restart a JVM with GC log rotation enabled, it overwrites the last un-rotated log file. That's not usually what we want. We like logs to have the timestamp or datestamp encoded in the file name for scripting, for future reference when logs are on a laptop for analysis with visualization tools (more important these days as GC logs for new garbage collectors get uglier and uglier), etc.
>
> It's possible to parameterize the log file name in scripts before it is passed to the JVM, but that's been do-able for years. And if you take a product such as Oracle Weblogic, it has a versionable, auto-deployed, centrally manageable config.xml, which we like to use as much as possible for, e.g., all the JVM args for all the JVMs in the domain. There's no facility for parameterized variables in config.xml. So you have to, again, do stuff in the launch script, which is more stuff to maintain, and so on.
>
> I'm willing to compile the patch for 6950794 and let you know if it compiles on Windows 7, 64 bit. I'm just a list observer but I can build it.
>
> Scott Stirling
> AT&T, Boston
>
> -----Original Message-----
> From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Yasumasa Suenaga
> Sent: Sunday, August 18, 2013 8:34 PM
> To: Yumin Qi
> Cc: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR: 7164841: Improvements to the GC log file rotation
>
> Hi Yumin,
>
> I've posted a RFE and patch for adding timestamp, PID, etc to log filename.
>
> JDK-6950794 : Make the GC log file name parameterized
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6950794
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html
>
> Your patch writes timestamp into logfile.
> Howeverm, in production system, we may want to check log generation through
> log filename. (e.g. ls command at Linux)
>
> Could you check my patch?
>
>
> Thanks,
>
> Yasumasa
>
> On 2013/08/16 0:35, Yumin Qi wrote:
>> Hi,
>>
>>     Can I have your review for this small changes?
>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/<http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>
>>      This is for a enhancement to add head/tail message to the logging files to assist reading GC output.
>>      1. modified prompt message if invalid arguments used for log rotating;
>>      2. add time and file name message to log file head/tail.
>>      3. for easily identify which log file is current, use file name like<filename>.n.current, after it reaches maximum size, rename it to<filename>.n
>>           On Windows, there is no F_OK (existing test) definition, F_OK is defined as "0" and for _access of VC++, it just describes:
>>
>> modevalue
>>
>> 	
>>
>> Checks file for
>>
>> 00
>>
>> 	
>>
>> Existence only
>>
>> 02
>>
>> 	
>>
>> Write-only
>>
>> 04
>>
>> 	
>>
>> Read-only
>>
>> 06
>>
>> 	
>>
>> Read and write
>>
>>
>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>> The definition are consistent with unistd.h.
>>
>>       Test: JPRT and jtreg.
>>
>>      Thanks
>>      Yumin
>


From daniel.daugherty at oracle.com  Mon Aug 19 17:18:13 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 19 Aug 2013 18:18:13 -0600
Subject: [JBS] (JDK-8023287) HOTSPOT_BUILD_COMPILER needs to support "Sun
	Studio 12u3"
In-Reply-To: <JIRA.4690770.1376943936000.9632.1376956391671@aojmv0001.oracle.com>
References: <JIRA.4690770.1376943936000@aojmv0001.oracle.com>
	<JIRA.4690770.1376943936000.9632.1376956391671@aojmv0001.oracle.com>
Message-ID: <5212B5C5.6080904@oracle.com>

HotSpot Runtime folks,

Here's a two line fix for getting the name of the SS12u3 compiler
correct. Not really worth a webrev (IMHO)...

The current (unfriendly) output looks like:

$ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-i586/bin/java 
-Xinternalversion
Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE 
(1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown 
Workshop:0x5120

$ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-x64/bin/java 
-Xinternalversion
Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE 
(1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown 
Workshop:0x5120

A couple of reviewers, please...

Dan


On 8/19/13 5:53 PM, Daniel Daugherty (JBS) wrote:
> Daniel Daugherty 
> <https://jbs.oracle.com/bugs/secure/ViewProfile.jspa?name=dcubed> 
> commented on Bug JDK-8023287 
> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
> *HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3"* 
> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>
>
> 	
> Here's the proposed change:
>
> $ hg diff
> diff -r e5003079dfa5 src/share/vm/runtime/vm_version.cpp
> --- a/src/share/vm/runtime/vm_version.cpp Fri Aug 16 10:06:58 2013 -0700
> +++ b/src/share/vm/runtime/vm_version.cpp Mon Aug 19 16:50:40 2013 -0700
> @@ -231,6 +231,8 @@ const char* Abstract_VM_Version::interna
>          #define HOTSPOT_BUILD_COMPILER "Workshop 5.9"
>        #elif __SUNPRO_CC == 0x5100
>          #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u1"
> + #elif __SUNPRO_CC == 0x5120
> + #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u3"
>        #else
>          #define HOTSPOT_BUILD_COMPILER "unknown Workshop:" 
> XSTR(__SUNPRO_CC)
>        #endif
>
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA 
> administrators 
> <https://jbs.oracle.com/bugs/secure/ContactAdministrators%21default.jspa>
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130819/c021274c/attachment-0001.html 

From david.holmes at oracle.com  Mon Aug 19 18:47:01 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 11:47:01 +1000
Subject: Request for Review 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh
	fails on 64-bit solaris
In-Reply-To: <5212231A.7070704@oracle.com>
References: <5203F024.9040006@oracle.com> <5212231A.7070704@oracle.com>
Message-ID: <5212CA95.3090304@oracle.com>

Hi Harold,

Should this also apply to OSX? Why is it restricted to 64-bit?

Thanks,
David

On 19/08/2013 11:52 PM, harold seigel wrote:
> Hi,
>
> I'm resending this RFR because I did not get any reviewers the first
> time.  If you have chance, please take a look.
>
> Thanks, Harold
>
> On 8/8/2013 3:23 PM, harold seigel wrote:
>> Hi,
>>
>> Please review this change to fix bug 7121403.  The test was rewritten
>> in Java and modified to properly determine when it is running on
>> 64-bit Solaris.
>>
>> The fix was tested by running the new test on 32-bit Linux, Solaris
>> Sparc, Solaris X86, and 64-bit Linux.
>>
>> webrev: http://cr.openjdk.java.net/~hseigel/bug_7121403/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_7121403/>
>>
>> bug: http://bugs.sun.com/view_bug.do?bug_id=7121403
>>
>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-7121403
>>
>> Thanks! Harold
>

From david.holmes at oracle.com  Mon Aug 19 18:54:06 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 11:54:06 +1000
Subject: Jarreorder and classlists
In-Reply-To: <521236FE.60409@oracle.com>
References: <521236FE.60409@oracle.com>
Message-ID: <5212CC3E.6040909@oracle.com>

Hi Erik,

Adding in hotspot-runtime-dev.

There is a lot of history here and I'm not sure who remembers all the 
details - if anyone. There are existing open bugs to re-assess the 
utility of the jarreorder (7032729) and to update the classlists (8005688).

David
------

On 20/08/2013 1:17 AM, Erik Joelsson wrote:
> Hello,
>
> I wonder if anyone knows more about the jarreorder tool and why we use it?
>
> As I understand it, we have precalculated classlists for each platform
> (most likely outdated) and the tool is used to make sure those classes
> end up in a specific order, last in rt.jar. I assume this is some kind
> of startup time optimization.
>
> I got some help from Claes in the performance team and did a quick run
> of a startup and footprint benchmark, comparing a build with the rt.jar
> reordered as normal and one where I simply turned off this feature and
> let the files end up in the default order. Our preliminary findings show
> that any difference between the two is negligible. Before we declare it
> useless, we might need to test with freshly generated classlists? Does
> anyone know how to generate them? Is there some other benefit of this
> that I might have missed?
>
> I would like to propose removing jarreorder to simplify the build. This
> would also enable faster incremental builds of the images target, by not
> having to rebuild the whole rt.jar every time.
>
> /Erik

From david.holmes at oracle.com  Mon Aug 19 19:16:23 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 12:16:23 +1000
Subject: RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh failed
	- round 2
In-Reply-To: <52125ACF.9050803@oracle.com>
References: <52125ACF.9050803@oracle.com>
Message-ID: <5212D177.8070907@oracle.com>

Hi Misha,

I have a couple of issues with this.

1. Missing @run tag

2. The shell script uses the COMPILEJDK to find the jar tool, but you 
are using JDKToolFinder which uses the TESTJDK - which means your test 
will be limited to running only on a full JDK (not a JRE). I thought the 
testlibrary supported using either the test-jdk or the compile-jdk but I 
don't see that now. :(

3. Not new with your change, but the unpacked files don't get cleaned up.

Thanks,
David

On 20/08/2013 3:50 AM, Mikhailo Seledtsov wrote:
> This is a round 2 review for this fix.
> Please review.
>
> Original review request (dated 16-July-2013) with the same subject was:
> "
> Please review this test fix. The change is a fix for the original bug,
> plus an update to the test condition to reflect new JVM behavior and a
> rewrite of an sh script test in Java.
> JBS: https://jbs.oracle.com/bugs/browse/JDK-8016029
> (Old) Webrev: http://cr.openjdk.java.net/~mseledtsov/6878713/webrev.00/
> <http://cr.openjdk.java.net/%7Emseledtsov/6878713/webrev.00/>
> "
>
>
> Change since last round of review:
>      JVM run-time technical leadership has made a decision to keep the
> testcase.jar until a long-term solution is in place for handling "Java
> assembler"-based and byte-code-based test cases.
>
> Here is the updated webrev and comments:
>      Webrev: http://cr.openjdk.java.net/~mseledtsov/8016029/webrev.01/
> <http://cr.openjdk.java.net/%7Emseledtsov/8016029/webrev.01/>
>      Testing: JPRT run for this test
> (2013-08-19-154813.mseledtsov.bugFixing01-hotspot-rt)
>
> Here are original notes:
> - the original behavior of the VM in this test case has changed, and the
> expected error message has changed as well. There is an extensive amount
> of information about this in the original bug, posted by Dan. The change
> was introduced in change-set: 4876:f75faf51e8c4 by Harold. Checking for
> the old expected messages has been removed from the test. This change is
> for JDK8 and forward, and no back-ports planned.
>
> - the flag -XX:+IgnoreUnrecognizedVMOptions has been removed to avoid
> masking a potential problem. If VM drops support for any of XX flags
> used in this test, it is better to know about it right away rather than
> mask it and silently pass/ignore.
>
> - the flag -XX:+PrintCommandLineFlags has been removed; if this
> information is desired, IMO it should be triggered either by a verbose
> mode of JTREG tools, or by hand, not by individual test(s).
>
> Round 2 notes:
> - the shell script has been replaced by Java
>
> - test has been moved to a new location, moving away from using bug
> numbers to using functional categories for test sub-folders
>
>
> Misha

From david.holmes at oracle.com  Mon Aug 19 19:27:04 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 12:27:04 +1000
Subject: [JBS] (JDK-8023287) HOTSPOT_BUILD_COMPILER needs to support "Sun
	Studio 12u3"
In-Reply-To: <5212B5C5.6080904@oracle.com>
References: <JIRA.4690770.1376943936000@aojmv0001.oracle.com>
	<JIRA.4690770.1376943936000.9632.1376956391671@aojmv0001.oracle.com>
	<5212B5C5.6080904@oracle.com>
Message-ID: <5212D3F8.7020909@oracle.com>

Hi Dan,

If we are fixing the SS12u3 support then there are makefile changes 
needed as well as I added to the bug report. Those changes are also 
trivial, and I think it would be good to get SS12u3 support in in one hit.

Thanks,
David

On 20/08/2013 10:18 AM, Daniel D. Daugherty wrote:
> HotSpot Runtime folks,
>
> Here's a two line fix for getting the name of the SS12u3 compiler
> correct. Not really worth a webrev (IMHO)...
>
> The current (unfriendly) output looks like:
>
> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-i586/bin/java
> -Xinternalversion
> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
> Workshop:0x5120
>
> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-x64/bin/java
> -Xinternalversion
> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
> Workshop:0x5120
>
> A couple of reviewers, please...
>
> Dan
>
>
> On 8/19/13 5:53 PM, Daniel Daugherty (JBS) wrote:
>> Daniel Daugherty
>> <https://jbs.oracle.com/bugs/secure/ViewProfile.jspa?name=dcubed>
>> commented on Bug JDK-8023287
>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>> *HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3"*
>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>>
>>
>> 	
>> Here's the proposed change:
>>
>> $ hg diff
>> diff -r e5003079dfa5 src/share/vm/runtime/vm_version.cpp
>> --- a/src/share/vm/runtime/vm_version.cpp Fri Aug 16 10:06:58 2013 -0700
>> +++ b/src/share/vm/runtime/vm_version.cpp Mon Aug 19 16:50:40 2013 -0700
>> @@ -231,6 +231,8 @@ const char* Abstract_VM_Version::interna
>>          #define HOTSPOT_BUILD_COMPILER "Workshop 5.9"
>>        #elif __SUNPRO_CC == 0x5100
>>          #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u1"
>> + #elif __SUNPRO_CC == 0x5120
>> + #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u3"
>>        #else
>>          #define HOTSPOT_BUILD_COMPILER "unknown Workshop:"
>> XSTR(__SUNPRO_CC)
>>        #endif
>>
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA
>> administrators
>> <https://jbs.oracle.com/bugs/secure/ContactAdministrators%21default.jspa>
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>

From gary.collins at oracle.com  Mon Aug 19 19:45:17 2013
From: gary.collins at oracle.com (Gary Collins)
Date: Mon, 19 Aug 2013 19:45:17 -0700
Subject: RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh
	failed - round 2
In-Reply-To: <5212D177.8070907@oracle.com>
References: <52125ACF.9050803@oracle.com> <5212D177.8070907@oracle.com>
Message-ID: <D3A7D789-A09B-4B42-92E6-A196CC414C0C@oracle.com>

Correct David.  They need to use compile jdk as you stated.

Not sure what the jdktoolfinder is



Gary

Sent from my iPad

On Aug 19, 2013, at 7:16 PM, David Holmes <david.holmes at oracle.com> wrote:

> Hi Misha,
> 
> I have a couple of issues with this.
> 
> 1. Missing @run tag
> 
> 2. The shell script uses the COMPILEJDK to find the jar tool, but you are using JDKToolFinder which uses the TESTJDK - which means your test will be limited to running only on a full JDK (not a JRE). I thought the testlibrary supported using either the test-jdk or the compile-jdk but I don't see that now. :(
> 
> 3. Not new with your change, but the unpacked files don't get cleaned up.
> 
> Thanks,
> David
> 
> On 20/08/2013 3:50 AM, Mikhailo Seledtsov wrote:
>> This is a round 2 review for this fix.
>> Please review.
>> 
>> Original review request (dated 16-July-2013) with the same subject was:
>> "
>> Please review this test fix. The change is a fix for the original bug,
>> plus an update to the test condition to reflect new JVM behavior and a
>> rewrite of an sh script test in Java.
>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8016029
>> (Old) Webrev: http://cr.openjdk.java.net/~mseledtsov/6878713/webrev.00/
>> <http://cr.openjdk.java.net/%7Emseledtsov/6878713/webrev.00/>
>> "
>> 
>> 
>> Change since last round of review:
>>     JVM run-time technical leadership has made a decision to keep the
>> testcase.jar until a long-term solution is in place for handling "Java
>> assembler"-based and byte-code-based test cases.
>> 
>> Here is the updated webrev and comments:
>>     Webrev: http://cr.openjdk.java.net/~mseledtsov/8016029/webrev.01/
>> <http://cr.openjdk.java.net/%7Emseledtsov/8016029/webrev.01/>
>>     Testing: JPRT run for this test
>> (2013-08-19-154813.mseledtsov.bugFixing01-hotspot-rt)
>> 
>> Here are original notes:
>> - the original behavior of the VM in this test case has changed, and the
>> expected error message has changed as well. There is an extensive amount
>> of information about this in the original bug, posted by Dan. The change
>> was introduced in change-set: 4876:f75faf51e8c4 by Harold. Checking for
>> the old expected messages has been removed from the test. This change is
>> for JDK8 and forward, and no back-ports planned.
>> 
>> - the flag -XX:+IgnoreUnrecognizedVMOptions has been removed to avoid
>> masking a potential problem. If VM drops support for any of XX flags
>> used in this test, it is better to know about it right away rather than
>> mask it and silently pass/ignore.
>> 
>> - the flag -XX:+PrintCommandLineFlags has been removed; if this
>> information is desired, IMO it should be triggered either by a verbose
>> mode of JTREG tools, or by hand, not by individual test(s).
>> 
>> Round 2 notes:
>> - the shell script has been replaced by Java
>> 
>> - test has been moved to a new location, moving away from using bug
>> numbers to using functional categories for test sub-folders
>> 
>> 
>> Misha

From daniel.daugherty at oracle.com  Mon Aug 19 19:57:52 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 19 Aug 2013 20:57:52 -0600
Subject: [JBS] (JDK-8023287) HOTSPOT_BUILD_COMPILER needs to support "Sun
	Studio 12u3"
In-Reply-To: <5212D3F8.7020909@oracle.com>
References: <JIRA.4690770.1376943936000@aojmv0001.oracle.com>
	<JIRA.4690770.1376943936000.9632.1376956391671@aojmv0001.oracle.com>
	<5212B5C5.6080904@oracle.com> <5212D3F8.7020909@oracle.com>
Message-ID: <5212DB30.7060802@oracle.com>

Sorry David, it is not my place to claim that SS12u3 is the official
compiler version. I'm just fixing the problem where the version is
reported in an unfriendly way when the bits are built with SS12u3.

As far as I am concerned, SS12u1 is still the official compiler
version and SS12u3 has not yet passed "validation".

Dan


On 8/19/13 8:27 PM, David Holmes wrote:
> Hi Dan,
>
> If we are fixing the SS12u3 support then there are makefile changes 
> needed as well as I added to the bug report. Those changes are also 
> trivial, and I think it would be good to get SS12u3 support in in one 
> hit.
>
> Thanks,
> David
>
> On 20/08/2013 10:18 AM, Daniel D. Daugherty wrote:
>> HotSpot Runtime folks,
>>
>> Here's a two line fix for getting the name of the SS12u3 compiler
>> correct. Not really worth a webrev (IMHO)...
>>
>> The current (unfriendly) output looks like:
>>
>> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-i586/bin/java
>> -Xinternalversion
>> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
>> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
>> Workshop:0x5120
>>
>> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-x64/bin/java
>> -Xinternalversion
>> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
>> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
>> Workshop:0x5120
>>
>> A couple of reviewers, please...
>>
>> Dan
>>
>>
>> On 8/19/13 5:53 PM, Daniel Daugherty (JBS) wrote:
>>> Daniel Daugherty
>>> <https://jbs.oracle.com/bugs/secure/ViewProfile.jspa?name=dcubed>
>>> commented on Bug JDK-8023287
>>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>>> *HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3"*
>>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>>>
>>>
>>>
>>> Here's the proposed change:
>>>
>>> $ hg diff
>>> diff -r e5003079dfa5 src/share/vm/runtime/vm_version.cpp
>>> --- a/src/share/vm/runtime/vm_version.cpp Fri Aug 16 10:06:58 2013 
>>> -0700
>>> +++ b/src/share/vm/runtime/vm_version.cpp Mon Aug 19 16:50:40 2013 
>>> -0700
>>> @@ -231,6 +231,8 @@ const char* Abstract_VM_Version::interna
>>>          #define HOTSPOT_BUILD_COMPILER "Workshop 5.9"
>>>        #elif __SUNPRO_CC == 0x5100
>>>          #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u1"
>>> + #elif __SUNPRO_CC == 0x5120
>>> + #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u3"
>>>        #else
>>>          #define HOTSPOT_BUILD_COMPILER "unknown Workshop:"
>>> XSTR(__SUNPRO_CC)
>>>        #endif
>>>
>>> This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA
>>> administrators
>>> <https://jbs.oracle.com/bugs/secure/ContactAdministrators%21default.jspa> 
>>>
>>> For more information on JIRA, see: 
>>> http://www.atlassian.com/software/jira
>>>
>>
>
>


From david.holmes at oracle.com  Mon Aug 19 20:17:23 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 13:17:23 +1000
Subject: RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh failed
	- round 2
In-Reply-To: <D3A7D789-A09B-4B42-92E6-A196CC414C0C@oracle.com>
References: <52125ACF.9050803@oracle.com> <5212D177.8070907@oracle.com>
	<D3A7D789-A09B-4B42-92E6-A196CC414C0C@oracle.com>
Message-ID: <5212DFC3.80804@oracle.com>

On 20/08/2013 12:45 PM, Gary Collins wrote:
> Correct David.  They need to use compile jdk as you stated.
>
> Not sure what the jdktoolfinder is

It is one of the utilities in the testlibrary to make it easier to do 
all this multi-process stuff from Java. Problem is that JDKToolFinder 
only returns tools from the test-jdk. But if the tool (javac, jar, jcmd, 
jps etc) is only incidental to what is being tested it can (usually but 
not always) come from the compile-jdk.

David

>
>
> Gary
>
> Sent from my iPad
>
> On Aug 19, 2013, at 7:16 PM, David Holmes <david.holmes at oracle.com> wrote:
>
>> Hi Misha,
>>
>> I have a couple of issues with this.
>>
>> 1. Missing @run tag
>>
>> 2. The shell script uses the COMPILEJDK to find the jar tool, but you are using JDKToolFinder which uses the TESTJDK - which means your test will be limited to running only on a full JDK (not a JRE). I thought the testlibrary supported using either the test-jdk or the compile-jdk but I don't see that now. :(
>>
>> 3. Not new with your change, but the unpacked files don't get cleaned up.
>>
>> Thanks,
>> David
>>
>> On 20/08/2013 3:50 AM, Mikhailo Seledtsov wrote:
>>> This is a round 2 review for this fix.
>>> Please review.
>>>
>>> Original review request (dated 16-July-2013) with the same subject was:
>>> "
>>> Please review this test fix. The change is a fix for the original bug,
>>> plus an update to the test condition to reflect new JVM behavior and a
>>> rewrite of an sh script test in Java.
>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8016029
>>> (Old) Webrev: http://cr.openjdk.java.net/~mseledtsov/6878713/webrev.00/
>>> <http://cr.openjdk.java.net/%7Emseledtsov/6878713/webrev.00/>
>>> "
>>>
>>>
>>> Change since last round of review:
>>>      JVM run-time technical leadership has made a decision to keep the
>>> testcase.jar until a long-term solution is in place for handling "Java
>>> assembler"-based and byte-code-based test cases.
>>>
>>> Here is the updated webrev and comments:
>>>      Webrev: http://cr.openjdk.java.net/~mseledtsov/8016029/webrev.01/
>>> <http://cr.openjdk.java.net/%7Emseledtsov/8016029/webrev.01/>
>>>      Testing: JPRT run for this test
>>> (2013-08-19-154813.mseledtsov.bugFixing01-hotspot-rt)
>>>
>>> Here are original notes:
>>> - the original behavior of the VM in this test case has changed, and the
>>> expected error message has changed as well. There is an extensive amount
>>> of information about this in the original bug, posted by Dan. The change
>>> was introduced in change-set: 4876:f75faf51e8c4 by Harold. Checking for
>>> the old expected messages has been removed from the test. This change is
>>> for JDK8 and forward, and no back-ports planned.
>>>
>>> - the flag -XX:+IgnoreUnrecognizedVMOptions has been removed to avoid
>>> masking a potential problem. If VM drops support for any of XX flags
>>> used in this test, it is better to know about it right away rather than
>>> mask it and silently pass/ignore.
>>>
>>> - the flag -XX:+PrintCommandLineFlags has been removed; if this
>>> information is desired, IMO it should be triggered either by a verbose
>>> mode of JTREG tools, or by hand, not by individual test(s).
>>>
>>> Round 2 notes:
>>> - the shell script has been replaced by Java
>>>
>>> - test has been moved to a new location, moving away from using bug
>>> numbers to using functional categories for test sub-folders
>>>
>>>
>>> Misha

From david.holmes at oracle.com  Mon Aug 19 20:24:10 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 13:24:10 +1000
Subject: [JBS] (JDK-8023287) HOTSPOT_BUILD_COMPILER needs to support "Sun
	Studio 12u3"
In-Reply-To: <5212DB30.7060802@oracle.com>
References: <JIRA.4690770.1376943936000@aojmv0001.oracle.com>
	<JIRA.4690770.1376943936000.9632.1376956391671@aojmv0001.oracle.com>
	<5212B5C5.6080904@oracle.com> <5212D3F8.7020909@oracle.com>
	<5212DB30.7060802@oracle.com>
Message-ID: <5212E15A.4040804@oracle.com>

On 20/08/2013 12:57 PM, Daniel D. Daugherty wrote:
> Sorry David, it is not my place to claim that SS12u3 is the official
> compiler version. I'm just fixing the problem where the version is
> reported in an unfriendly way when the bits are built with SS12u3.
>
> As far as I am concerned, SS12u1 is still the official compiler
> version and SS12u3 has not yet passed "validation".

You are of course correct - the updates to the makefile should only 
happen if/when we switch to SS12u3 as the official compiler.

Sorry, just trying to kill two birds with one changset ;-)

Reviewed.

Thanks,
David

> Dan
>
>
> On 8/19/13 8:27 PM, David Holmes wrote:
>> Hi Dan,
>>
>> If we are fixing the SS12u3 support then there are makefile changes
>> needed as well as I added to the bug report. Those changes are also
>> trivial, and I think it would be good to get SS12u3 support in in one
>> hit.
>>
>> Thanks,
>> David
>>
>> On 20/08/2013 10:18 AM, Daniel D. Daugherty wrote:
>>> HotSpot Runtime folks,
>>>
>>> Here's a two line fix for getting the name of the SS12u3 compiler
>>> correct. Not really worth a webrev (IMHO)...
>>>
>>> The current (unfriendly) output looks like:
>>>
>>> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-i586/bin/java
>>> -Xinternalversion
>>> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
>>> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
>>> Workshop:0x5120
>>>
>>> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-x64/bin/java
>>> -Xinternalversion
>>> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
>>> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
>>> Workshop:0x5120
>>>
>>> A couple of reviewers, please...
>>>
>>> Dan
>>>
>>>
>>> On 8/19/13 5:53 PM, Daniel Daugherty (JBS) wrote:
>>>> Daniel Daugherty
>>>> <https://jbs.oracle.com/bugs/secure/ViewProfile.jspa?name=dcubed>
>>>> commented on Bug JDK-8023287
>>>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>>>> *HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3"*
>>>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>>>>
>>>>
>>>>
>>>> Here's the proposed change:
>>>>
>>>> $ hg diff
>>>> diff -r e5003079dfa5 src/share/vm/runtime/vm_version.cpp
>>>> --- a/src/share/vm/runtime/vm_version.cpp Fri Aug 16 10:06:58 2013
>>>> -0700
>>>> +++ b/src/share/vm/runtime/vm_version.cpp Mon Aug 19 16:50:40 2013
>>>> -0700
>>>> @@ -231,6 +231,8 @@ const char* Abstract_VM_Version::interna
>>>>          #define HOTSPOT_BUILD_COMPILER "Workshop 5.9"
>>>>        #elif __SUNPRO_CC == 0x5100
>>>>          #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u1"
>>>> + #elif __SUNPRO_CC == 0x5120
>>>> + #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u3"
>>>>        #else
>>>>          #define HOTSPOT_BUILD_COMPILER "unknown Workshop:"
>>>> XSTR(__SUNPRO_CC)
>>>>        #endif
>>>>
>>>> This message is automatically generated by JIRA.
>>>> If you think it was sent incorrectly, please contact your JIRA
>>>> administrators
>>>> <https://jbs.oracle.com/bugs/secure/ContactAdministrators%21default.jspa>
>>>>
>>>> For more information on JIRA, see:
>>>> http://www.atlassian.com/software/jira
>>>>
>>>
>>
>>
>

From daniel.daugherty at oracle.com  Mon Aug 19 20:30:22 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 19 Aug 2013 21:30:22 -0600
Subject: [JBS] (JDK-8023287) HOTSPOT_BUILD_COMPILER needs to support "Sun
	Studio 12u3"
In-Reply-To: <5212E15A.4040804@oracle.com>
References: <JIRA.4690770.1376943936000@aojmv0001.oracle.com>
	<JIRA.4690770.1376943936000.9632.1376956391671@aojmv0001.oracle.com>
	<5212B5C5.6080904@oracle.com> <5212D3F8.7020909@oracle.com>
	<5212DB30.7060802@oracle.com> <5212E15A.4040804@oracle.com>
Message-ID: <5212E2CE.30207@oracle.com>

On 8/19/13 9:24 PM, David Holmes wrote:
> On 20/08/2013 12:57 PM, Daniel D. Daugherty wrote:
>> Sorry David, it is not my place to claim that SS12u3 is the official
>> compiler version. I'm just fixing the problem where the version is
>> reported in an unfriendly way when the bits are built with SS12u3.
>>
>> As far as I am concerned, SS12u1 is still the official compiler
>> version and SS12u3 has not yet passed "validation".
>
> You are of course correct - the updates to the makefile should only 
> happen if/when we switch to SS12u3 as the official compiler.
>
> Sorry, just trying to kill two birds with one changset ;-)

Thanks for your understanding!


> Reviewed.

Thanks for the review!

Dan


>
> Thanks,
> David
>
>> Dan
>>
>>
>> On 8/19/13 8:27 PM, David Holmes wrote:
>>> Hi Dan,
>>>
>>> If we are fixing the SS12u3 support then there are makefile changes
>>> needed as well as I added to the bug report. Those changes are also
>>> trivial, and I think it would be good to get SS12u3 support in in one
>>> hit.
>>>
>>> Thanks,
>>> David
>>>
>>> On 20/08/2013 10:18 AM, Daniel D. Daugherty wrote:
>>>> HotSpot Runtime folks,
>>>>
>>>> Here's a two line fix for getting the name of the SS12u3 compiler
>>>> correct. Not really worth a webrev (IMHO)...
>>>>
>>>> The current (unfriendly) output looks like:
>>>>
>>>> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-i586/bin/java
>>>> -Xinternalversion
>>>> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
>>>> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
>>>> Workshop:0x5120
>>>>
>>>> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-x64/bin/java
>>>> -Xinternalversion
>>>> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
>>>> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
>>>> Workshop:0x5120
>>>>
>>>> A couple of reviewers, please...
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 8/19/13 5:53 PM, Daniel Daugherty (JBS) wrote:
>>>>> Daniel Daugherty
>>>>> <https://jbs.oracle.com/bugs/secure/ViewProfile.jspa?name=dcubed>
>>>>> commented on Bug JDK-8023287
>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>>>>> *HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3"*
>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>>>>>
>>>>>
>>>>>
>>>>> Here's the proposed change:
>>>>>
>>>>> $ hg diff
>>>>> diff -r e5003079dfa5 src/share/vm/runtime/vm_version.cpp
>>>>> --- a/src/share/vm/runtime/vm_version.cpp Fri Aug 16 10:06:58 2013
>>>>> -0700
>>>>> +++ b/src/share/vm/runtime/vm_version.cpp Mon Aug 19 16:50:40 2013
>>>>> -0700
>>>>> @@ -231,6 +231,8 @@ const char* Abstract_VM_Version::interna
>>>>>          #define HOTSPOT_BUILD_COMPILER "Workshop 5.9"
>>>>>        #elif __SUNPRO_CC == 0x5100
>>>>>          #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u1"
>>>>> + #elif __SUNPRO_CC == 0x5120
>>>>> + #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u3"
>>>>>        #else
>>>>>          #define HOTSPOT_BUILD_COMPILER "unknown Workshop:"
>>>>> XSTR(__SUNPRO_CC)
>>>>>        #endif
>>>>>
>>>>> This message is automatically generated by JIRA.
>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>> administrators
>>>>> <https://jbs.oracle.com/bugs/secure/ContactAdministrators%21default.jspa> 
>>>>>
>>>>>
>>>>> For more information on JIRA, see:
>>>>> http://www.atlassian.com/software/jira
>>>>>
>>>>
>>>
>>>
>>
>
>


From christian.tornqvist at oracle.com  Mon Aug 19 21:10:19 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Tue, 20 Aug 2013 00:10:19 -0400
Subject: RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh
	failed	- round 2
In-Reply-To: <5212D177.8070907@oracle.com>
References: <52125ACF.9050803@oracle.com> <5212D177.8070907@oracle.com>
Message-ID: <00a501ce9d5b$2f5bc050$8e1340f0$@oracle.com>

Hi David,

>1. Missing @run tag

The default action (when there is no @compile or @run tag ) of jtreg is '@run main Test.java'

>3. Not new with your change, but the unpacked files don't get cleaned up.

Jtreg will clean up the scratch directory when the test has passed, this not something the tests should do themselves

Thanks,
Christian

-----Original Message-----
From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
Sent: Monday, August 19, 2013 10:16 PM
To: Mikhailo Seledtsov
Cc: hotspot-runtime-dev
Subject: Re: RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh failed - round 2

Hi Misha,

I have a couple of issues with this.

1. Missing @run tag

2. The shell script uses the COMPILEJDK to find the jar tool, but you are using JDKToolFinder which uses the TESTJDK - which means your test will be limited to running only on a full JDK (not a JRE). I thought the testlibrary supported using either the test-jdk or the compile-jdk but I don't see that now. :(

3. Not new with your change, but the unpacked files don't get cleaned up.

Thanks,
David

On 20/08/2013 3:50 AM, Mikhailo Seledtsov wrote:
> This is a round 2 review for this fix.
> Please review.
>
> Original review request (dated 16-July-2013) with the same subject was:
> "
> Please review this test fix. The change is a fix for the original bug, 
> plus an update to the test condition to reflect new JVM behavior and a 
> rewrite of an sh script test in Java.
> JBS: https://jbs.oracle.com/bugs/browse/JDK-8016029
> (Old) Webrev: 
> http://cr.openjdk.java.net/~mseledtsov/6878713/webrev.00/
> <http://cr.openjdk.java.net/%7Emseledtsov/6878713/webrev.00/>
> "
>
>
> Change since last round of review:
>      JVM run-time technical leadership has made a decision to keep the 
> testcase.jar until a long-term solution is in place for handling "Java 
> assembler"-based and byte-code-based test cases.
>
> Here is the updated webrev and comments:
>      Webrev: http://cr.openjdk.java.net/~mseledtsov/8016029/webrev.01/
> <http://cr.openjdk.java.net/%7Emseledtsov/8016029/webrev.01/>
>      Testing: JPRT run for this test
> (2013-08-19-154813.mseledtsov.bugFixing01-hotspot-rt)
>
> Here are original notes:
> - the original behavior of the VM in this test case has changed, and 
> the expected error message has changed as well. There is an extensive 
> amount of information about this in the original bug, posted by Dan. 
> The change was introduced in change-set: 4876:f75faf51e8c4 by Harold. 
> Checking for the old expected messages has been removed from the test. 
> This change is for JDK8 and forward, and no back-ports planned.
>
> - the flag -XX:+IgnoreUnrecognizedVMOptions has been removed to avoid 
> masking a potential problem. If VM drops support for any of XX flags 
> used in this test, it is better to know about it right away rather 
> than mask it and silently pass/ignore.
>
> - the flag -XX:+PrintCommandLineFlags has been removed; if this 
> information is desired, IMO it should be triggered either by a verbose 
> mode of JTREG tools, or by hand, not by individual test(s).
>
> Round 2 notes:
> - the shell script has been replaced by Java
>
> - test has been moved to a new location, moving away from using bug 
> numbers to using functional categories for test sub-folders
>
>
> Misha


From david.holmes at oracle.com  Mon Aug 19 21:16:30 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 14:16:30 +1000
Subject: RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh failed
	- round 2
In-Reply-To: <00a501ce9d5b$2f5bc050$8e1340f0$@oracle.com>
References: <52125ACF.9050803@oracle.com> <5212D177.8070907@oracle.com>
	<00a501ce9d5b$2f5bc050$8e1340f0$@oracle.com>
Message-ID: <5212ED9E.7090405@oracle.com>

Hi Christian,

On 20/08/2013 2:10 PM, Christian Tornqvist wrote:
> Hi David,
>
>> 1. Missing @run tag
>
> The default action (when there is no @compile or @run tag ) of jtreg is '@run main Test.java'

Okay, but there have been a few issues lately with misconfigured tags so 
I think it preferable to be explicit.

>> 3. Not new with your change, but the unpacked files don't get cleaned up.
>
> Jtreg will clean up the scratch directory when the test has passed, this not something the tests should do themselves

I see we are relying on jtreg to do the cleanup here, but I like tests 
that can be run outside of jtreg too and not cause problems and/or a 
mess. But I won't push it. :)

Thanks,
David

> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
> Sent: Monday, August 19, 2013 10:16 PM
> To: Mikhailo Seledtsov
> Cc: hotspot-runtime-dev
> Subject: Re: RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh failed - round 2
>
> Hi Misha,
>
> I have a couple of issues with this.
>
> 1. Missing @run tag
>
> 2. The shell script uses the COMPILEJDK to find the jar tool, but you are using JDKToolFinder which uses the TESTJDK - which means your test will be limited to running only on a full JDK (not a JRE). I thought the testlibrary supported using either the test-jdk or the compile-jdk but I don't see that now. :(
>
> 3. Not new with your change, but the unpacked files don't get cleaned up.
>
> Thanks,
> David
>
> On 20/08/2013 3:50 AM, Mikhailo Seledtsov wrote:
>> This is a round 2 review for this fix.
>> Please review.
>>
>> Original review request (dated 16-July-2013) with the same subject was:
>> "
>> Please review this test fix. The change is a fix for the original bug,
>> plus an update to the test condition to reflect new JVM behavior and a
>> rewrite of an sh script test in Java.
>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8016029
>> (Old) Webrev:
>> http://cr.openjdk.java.net/~mseledtsov/6878713/webrev.00/
>> <http://cr.openjdk.java.net/%7Emseledtsov/6878713/webrev.00/>
>> "
>>
>>
>> Change since last round of review:
>>       JVM run-time technical leadership has made a decision to keep the
>> testcase.jar until a long-term solution is in place for handling "Java
>> assembler"-based and byte-code-based test cases.
>>
>> Here is the updated webrev and comments:
>>       Webrev: http://cr.openjdk.java.net/~mseledtsov/8016029/webrev.01/
>> <http://cr.openjdk.java.net/%7Emseledtsov/8016029/webrev.01/>
>>       Testing: JPRT run for this test
>> (2013-08-19-154813.mseledtsov.bugFixing01-hotspot-rt)
>>
>> Here are original notes:
>> - the original behavior of the VM in this test case has changed, and
>> the expected error message has changed as well. There is an extensive
>> amount of information about this in the original bug, posted by Dan.
>> The change was introduced in change-set: 4876:f75faf51e8c4 by Harold.
>> Checking for the old expected messages has been removed from the test.
>> This change is for JDK8 and forward, and no back-ports planned.
>>
>> - the flag -XX:+IgnoreUnrecognizedVMOptions has been removed to avoid
>> masking a potential problem. If VM drops support for any of XX flags
>> used in this test, it is better to know about it right away rather
>> than mask it and silently pass/ignore.
>>
>> - the flag -XX:+PrintCommandLineFlags has been removed; if this
>> information is desired, IMO it should be triggered either by a verbose
>> mode of JTREG tools, or by hand, not by individual test(s).
>>
>> Round 2 notes:
>> - the shell script has been replaced by Java
>>
>> - test has been moved to a new location, moving away from using bug
>> numbers to using functional categories for test sub-folders
>>
>>
>> Misha
>

From erik.helin at oracle.com  Mon Aug 19 22:25:00 2013
From: erik.helin at oracle.com (erik.helin at oracle.com)
Date: Tue, 20 Aug 2013 05:25:00 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130820052509.C4000489D1@hg.openjdk.java.net>

Changeset: 1a8fb39bdbc4
Author:    ehelin
Date:      2013-08-07 16:47 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1a8fb39bdbc4

8014659: NPG: performance counters for compressed klass space
Reviewed-by: mgerdin, coleenp, hseigel, jmasa, ctornqvi

! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp
! src/share/vm/memory/metaspaceCounters.hpp
! src/share/vm/memory/universe.cpp
+ test/gc/metaspace/TestMetaspacePerfCounters.java
+ test/testlibrary/AssertsTest.java
+ test/testlibrary/com/oracle/java/testlibrary/Asserts.java
+ test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java
+ test/testlibrary/com/oracle/java/testlibrary/InMemoryJavaCompiler.java
+ test/testlibrary/com/oracle/java/testlibrary/InputArguments.java
+ test/testlibrary/com/oracle/java/testlibrary/PerfCounter.java
+ test/testlibrary/com/oracle/java/testlibrary/PerfCounters.java

Changeset: 878bb0b7e799
Author:    ehelin
Date:      2013-08-19 17:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/878bb0b7e799

Merge



From kevin.walls at oracle.com  Tue Aug 20 00:45:13 2013
From: kevin.walls at oracle.com (kevin.walls at oracle.com)
Date: Tue, 20 Aug 2013 07:45:13 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130820074520.2A6CF489D9@hg.openjdk.java.net>

Changeset: 10c59b8021ec
Author:    kevinw
Date:      2013-08-19 14:28 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/10c59b8021ec

8022655: ClassDump ignored jarStream setting
Reviewed-by: minqi, sla

! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
! test/compiler/ciReplay/common.sh

Changeset: 9011aa6843ce
Author:    kevinw
Date:      2013-08-19 22:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9011aa6843ce

Merge



From dmitry.samersoff at oracle.com  Tue Aug 20 02:14:07 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 20 Aug 2013 13:14:07 +0400
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <52124395.2000709@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
	<52124395.2000709@oracle.com>
Message-ID: <5213335F.6060705@oracle.com>

On 2013-08-19 20:11, Gerard Ziemski wrote:
> hi Staffan,
> 
> A search on the topic of Mac thread id reveals that pretty much everyone
> (including Apple itself) uses pthread_mach_thread_np() for thread id, so
> it looks like you're correct to use it.
> 
> I do have some more quick feedback/questions:
> 
> 1. Could the "just checking" string in guarantee() be set to something
> more informative, like "thread id doesn't exist"?
> 
> 2. Why are we using the the "::" C++ name space before mach/pthread C
> APIs calls? I understand that you might be just following the existing
> pattern in the file, I'm just wondering if you, or anyone knows why.

C++ :: means global scope and it solves naming conflict if you would
have pthread_mach_thread_np() in your namespace and don't specify
namespace explicitly.

It's very good practice to always use :: for all os functions we call.

-Dmitry

> 3. Also not directly related to your fix, but do you know why we need
> both "set_thread_id" and "set_unique_thread_id"
> 
> 
> cheers
> 
> 
> On 8/19/2013 4:08 AM, Staffan Larsen wrote:
>> We are using the mach thread port name as the os thread identifier on
>> OS X. We get this value by calling mach_thread_self(), but we (I)
>> didn't realize that this "port" resource is reference counted and
>> mach_thread_self() increases the reference count, but we never call
>> mach_port_deallocate() to decrease the reference count. This leads to
>> a resource leak and eventually mach_thread_self() will return 0 to
>> indicate that we are out of ports. Running out of ports causes the
>> pthreads implementation (which is built on top of mach) to spin
>> forever in some calls (most notably in this case pthread_kill()).
>>
>> One way to fix this is to make sure we call mach_port_deallocate() for
>> each call to mach_thread_self(). However, this adds extra complexity
>> to the code and also makes it slower. Another solution is to ask
>> pthreads for the mach port name that it already has. Pthreads provides
>> the function pthread_mach_thread_np() for this purpose. In this case
>> there is no need to deallocate the port since pthread_mach_thread_np()
>> will not increase the reference count (and pthreads will call
>> deallocate on the port once the thread terminates).
>>
>> This fix has been verified by seeing that the number of ports the
>> process has allocated does not increase in Activity Monitor (or top).
>> It has also passed JPRT testing on all platforms.
>>
>> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
>> (there is not publicly visible bug for this)
>>
>> Thanks,
>> /Staffan
> 


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

From jiangli.zhou at oracle.com  Tue Aug 20 03:11:16 2013
From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com)
Date: Tue, 20 Aug 2013 10:11:16 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130820101120.EDE64489DC@hg.openjdk.java.net>

Changeset: e22ee8e7ae62
Author:    jiangli
Date:      2013-08-19 14:59 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e22ee8e7ae62

8021948: Change InstanceKlass::_source_file_name and _generic_signature from Symbol* to constant pool indexes.
Summary: Change InstanceKlass::_source_file_name and _generic_signature to u2 fields.
Reviewed-by: coleenp, iklam

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: aeebffb56606
Author:    jiangli
Date:      2013-08-20 00:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aeebffb56606

Merge



From vladimir.kempik at oracle.com  Tue Aug 20 04:44:33 2013
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Tue, 20 Aug 2013 15:44:33 +0400
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
Message-ID: <521356A1.9010507@oracle.com>

Hi all,

Could I have a couple of reviews for this change?

http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/

Running WebLogic server with 1.8.0 encounters this error:

Caused by: java.lang.IllegalArgumentException: committed = 86482944 
should be < max = 50331648

         at java.lang.management.MemoryUsage.<init>(MemoryUsage.java:162)

         at sun.management.MemoryImpl.getMemoryUsage0(Native Method)

         at 
sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75)

        ... 37 more

There is a bug in jmm_GetMemoryUsage here -- if a memory region does not 
define a maximum size, then the total_max is not updated:
       if (u.max_size() == (size_t)-1) {
         has_undefined_max_size = true;
       }
       if (!has_undefined_max_size) {
         total_max += u.max_size();
       }

It started with JDK version 1.8.0-ea-b97.

In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is 
next comment

// if any one of the memory pool has undefined init_size or max_size,
// set it to -1

But code doing this is missing, so I've added the code to do exactly 
what comment says.

Thanks,
Vladimir


From dmitry.samersoff at oracle.com  Tue Aug 20 05:00:21 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 20 Aug 2013 16:00:21 +0400
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <521356A1.9010507@oracle.com>
References: <521356A1.9010507@oracle.com>
Message-ID: <52135A55.9010608@oracle.com>

Vladimir,

Explicit cast of -1 to size_t is required.

-Dmitry

On 2013-08-20 15:44, Vladimir Kempik wrote:
> Hi all,
> 
> Could I have a couple of reviews for this change?
> 
> http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/
> 
> Running WebLogic server with 1.8.0 encounters this error:
> 
> Caused by: java.lang.IllegalArgumentException: committed = 86482944
> should be < max = 50331648
> 
>         at java.lang.management.MemoryUsage.<init>(MemoryUsage.java:162)
> 
>         at sun.management.MemoryImpl.getMemoryUsage0(Native Method)
> 
>         at
> sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75)
> 
>        ... 37 more
> 
> There is a bug in jmm_GetMemoryUsage here -- if a memory region does not
> define a maximum size, then the total_max is not updated:
>       if (u.max_size() == (size_t)-1) {
>         has_undefined_max_size = true;
>       }
>       if (!has_undefined_max_size) {
>         total_max += u.max_size();
>       }
> 
> It started with JDK version 1.8.0-ea-b97.
> 
> In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is
> next comment
> 
> // if any one of the memory pool has undefined init_size or max_size,
> // set it to -1
> 
> But code doing this is missing, so I've added the code to do exactly
> what comment says.
> 
> Thanks,
> Vladimir
> 


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

From david.holmes at oracle.com  Tue Aug 20 05:14:26 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 22:14:26 +1000
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <521356A1.9010507@oracle.com>
References: <521356A1.9010507@oracle.com>
Message-ID: <52135DA2.4070403@oracle.com>

On 20/08/2013 9:44 PM, Vladimir Kempik wrote:
> Hi all,
>
> Could I have a couple of reviews for this change?
>
> http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/
>
> Running WebLogic server with 1.8.0 encounters this error:
>
> Caused by: java.lang.IllegalArgumentException: committed = 86482944
> should be < max = 50331648
>
>          at java.lang.management.MemoryUsage.<init>(MemoryUsage.java:162)
>
>          at sun.management.MemoryImpl.getMemoryUsage0(Native Method)
>
>          at
> sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75)
>
>         ... 37 more
>
> There is a bug in jmm_GetMemoryUsage here -- if a memory region does not
> define a maximum size, then the total_max is not updated:
>        if (u.max_size() == (size_t)-1) {
>          has_undefined_max_size = true;
>        }
>        if (!has_undefined_max_size) {
>          total_max += u.max_size();
>        }
>
> It started with JDK version 1.8.0-ea-b97.
>
> In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is
> next comment
>
> // if any one of the memory pool has undefined init_size or max_size,
> // set it to -1
>
> But code doing this is missing, so I've added the code to do exactly
> what comment says.

That doesn't make a lot of sense to me. Why would a pool have undefined 
values? If a subset of pools have undefined values why report completely 
fallacious values of -1?

It also isn't clear how this relates to the "committed" value in the 
failure. What gets reported now?

Thanks,
David

> Thanks,
> Vladimir
>

From staffan.larsen at oracle.com  Tue Aug 20 05:19:35 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 20 Aug 2013 14:19:35 +0200
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <521356A1.9010507@oracle.com>
References: <521356A1.9010507@oracle.com>
Message-ID: <E57A5A3B-F9AE-41D1-96ED-A806EC9D054D@oracle.com>

Looks good. Metaspace is the first memory pool with an undefined maximum size.

/Staffan

On 20 aug 2013, at 13:44, Vladimir Kempik <vladimir.kempik at oracle.com> wrote:

> Hi all,
> 
> Could I have a couple of reviews for this change?
> 
> http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/
> 
> Running WebLogic server with 1.8.0 encounters this error:
> 
> Caused by: java.lang.IllegalArgumentException: committed = 86482944 should be < max = 50331648
> 
>        at java.lang.management.MemoryUsage.<init>(MemoryUsage.java:162)
> 
>        at sun.management.MemoryImpl.getMemoryUsage0(Native Method)
> 
>        at sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75)
> 
>       ... 37 more
> 
> There is a bug in jmm_GetMemoryUsage here -- if a memory region does not define a maximum size, then the total_max is not updated:
>      if (u.max_size() == (size_t)-1) {
>        has_undefined_max_size = true;
>      }
>      if (!has_undefined_max_size) {
>        total_max += u.max_size();
>      }
> 
> It started with JDK version 1.8.0-ea-b97.
> 
> In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is next comment
> 
> // if any one of the memory pool has undefined init_size or max_size,
> // set it to -1
> 
> But code doing this is missing, so I've added the code to do exactly what comment says.
> 
> Thanks,
> Vladimir
> 


From staffan.larsen at oracle.com  Tue Aug 20 05:38:50 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 20 Aug 2013 14:38:50 +0200
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <52135DA2.4070403@oracle.com>
References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com>
Message-ID: <8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com>


On 20 aug 2013, at 14:14, David Holmes <David.Holmes at oracle.com> wrote:

> On 20/08/2013 9:44 PM, Vladimir Kempik wrote:
>> Hi all,
>> 
>> Could I have a couple of reviews for this change?
>> 
>> http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/
>> 
>> Running WebLogic server with 1.8.0 encounters this error:
>> 
>> Caused by: java.lang.IllegalArgumentException: committed = 86482944
>> should be < max = 50331648
>> 
>>         at java.lang.management.MemoryUsage.<init>(MemoryUsage.java:162)
>> 
>>         at sun.management.MemoryImpl.getMemoryUsage0(Native Method)
>> 
>>         at
>> sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75)
>> 
>>        ... 37 more
>> 
>> There is a bug in jmm_GetMemoryUsage here -- if a memory region does not
>> define a maximum size, then the total_max is not updated:
>>       if (u.max_size() == (size_t)-1) {
>>         has_undefined_max_size = true;
>>       }
>>       if (!has_undefined_max_size) {
>>         total_max += u.max_size();
>>       }
>> 
>> It started with JDK version 1.8.0-ea-b97.
>> 
>> In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is
>> next comment
>> 
>> // if any one of the memory pool has undefined init_size or max_size,
>> // set it to -1
>> 
>> But code doing this is missing, so I've added the code to do exactly
>> what comment says.
> 
> That doesn't make a lot of sense to me. Why would a pool have undefined values?

The Metaspace pool has no max value (unless you specify -XX:MaxMetaspaceSize=), thus undefined.

> If a subset of pools have undefined values why report completely fallacious values of -1?

The javadoc for MemoryUsage says getMax() returns -1 if the maximum memory size is undefined.

> It also isn't clear how this relates to the "committed" value in the failure. What gets reported now?

I guess there can still be a committed value even if we don't have a max value for how much we might commit in the future: used <= committed <= max.

/Staffan

> 
> Thanks,
> David
> 
>> Thanks,
>> Vladimir
>> 


From coleen.phillimore at oracle.com  Tue Aug 20 07:52:38 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 20 Aug 2013 10:52:38 -0400
Subject: [JBS] (JDK-8023287) HOTSPOT_BUILD_COMPILER needs to support "Sun
	Studio 12u3"
In-Reply-To: <5212E2CE.30207@oracle.com>
References: <JIRA.4690770.1376943936000@aojmv0001.oracle.com>
	<JIRA.4690770.1376943936000.9632.1376956391671@aojmv0001.oracle.com>
	<5212B5C5.6080904@oracle.com> <5212D3F8.7020909@oracle.com>
	<5212DB30.7060802@oracle.com> <5212E15A.4040804@oracle.com>
	<5212E2CE.30207@oracle.com>
Message-ID: <521382B6.2040007@oracle.com>


Even though SS12u3 compiler upgrade isn't ready yet, this change looks 
good for when it is.

Coleen

On 08/19/2013 11:30 PM, Daniel D. Daugherty wrote:
> On 8/19/13 9:24 PM, David Holmes wrote:
>> On 20/08/2013 12:57 PM, Daniel D. Daugherty wrote:
>>> Sorry David, it is not my place to claim that SS12u3 is the official
>>> compiler version. I'm just fixing the problem where the version is
>>> reported in an unfriendly way when the bits are built with SS12u3.
>>>
>>> As far as I am concerned, SS12u1 is still the official compiler
>>> version and SS12u3 has not yet passed "validation".
>>
>> You are of course correct - the updates to the makefile should only 
>> happen if/when we switch to SS12u3 as the official compiler.
>>
>> Sorry, just trying to kill two birds with one changset ;-)
>
> Thanks for your understanding!
>
>
>> Reviewed.
>
> Thanks for the review!
>
> Dan
>
>
>>
>> Thanks,
>> David
>>
>>> Dan
>>>
>>>
>>> On 8/19/13 8:27 PM, David Holmes wrote:
>>>> Hi Dan,
>>>>
>>>> If we are fixing the SS12u3 support then there are makefile changes
>>>> needed as well as I added to the bug report. Those changes are also
>>>> trivial, and I think it would be good to get SS12u3 support in in one
>>>> hit.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 20/08/2013 10:18 AM, Daniel D. Daugherty wrote:
>>>>> HotSpot Runtime folks,
>>>>>
>>>>> Here's a two line fix for getting the name of the SS12u3 compiler
>>>>> correct. Not really worth a webrev (IMHO)...
>>>>>
>>>>> The current (unfriendly) output looks like:
>>>>>
>>>>> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-i586/bin/java
>>>>> -Xinternalversion
>>>>> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
>>>>> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
>>>>> Workshop:0x5120
>>>>>
>>>>> $ /java/re/jdk/1.8.0/promoted/all/b100/binaries/solaris-x64/bin/java
>>>>> -Xinternalversion
>>>>> Java HotSpot(TM) Server VM (25.0-b42) for solaris-x86 JRE
>>>>> (1.8.0-ea-b100), built on Jul 25 2013 05:03:21 by "" with unknown
>>>>> Workshop:0x5120
>>>>>
>>>>> A couple of reviewers, please...
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 8/19/13 5:53 PM, Daniel Daugherty (JBS) wrote:
>>>>>> Daniel Daugherty
>>>>>> <https://jbs.oracle.com/bugs/secure/ViewProfile.jspa?name=dcubed>
>>>>>> commented on Bug JDK-8023287
>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>>>>>> *HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3"*
>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8023287>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Here's the proposed change:
>>>>>>
>>>>>> $ hg diff
>>>>>> diff -r e5003079dfa5 src/share/vm/runtime/vm_version.cpp
>>>>>> --- a/src/share/vm/runtime/vm_version.cpp Fri Aug 16 10:06:58 2013
>>>>>> -0700
>>>>>> +++ b/src/share/vm/runtime/vm_version.cpp Mon Aug 19 16:50:40 2013
>>>>>> -0700
>>>>>> @@ -231,6 +231,8 @@ const char* Abstract_VM_Version::interna
>>>>>>          #define HOTSPOT_BUILD_COMPILER "Workshop 5.9"
>>>>>>        #elif __SUNPRO_CC == 0x5100
>>>>>>          #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u1"
>>>>>> + #elif __SUNPRO_CC == 0x5120
>>>>>> + #define HOTSPOT_BUILD_COMPILER "Sun Studio 12u3"
>>>>>>        #else
>>>>>>          #define HOTSPOT_BUILD_COMPILER "unknown Workshop:"
>>>>>> XSTR(__SUNPRO_CC)
>>>>>>        #endif
>>>>>>
>>>>>> This message is automatically generated by JIRA.
>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>> administrators
>>>>>> <https://jbs.oracle.com/bugs/secure/ContactAdministrators%21default.jspa> 
>>>>>>
>>>>>>
>>>>>> For more information on JIRA, see:
>>>>>> http://www.atlassian.com/software/jira
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From vladimir.x.ivanov at oracle.com  Tue Aug 20 10:05:45 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 20 Aug 2013 21:05:45 +0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
Message-ID: <5213A1E9.1090002@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
201 lines changed: 201 ins; 0 del; 0 mod;

Some classes in j.l.invoke have circular dependencies between them which 
leads to deadlocks during class initialization when multiple threads 
exercise JSR292 functionality.

JSR292 core classes are among "well-known" classes to VM and they are 
preloaded during VM startup (see 
SystemDictionary::initialize_preloaded_classes). However, it doesn't 
force preloaded classes to be initialized (doesn't execute static 
initializers). Thus, these classes should be explicitly pre-initialized 
in order to avoid deadlocks.

Based on my observations of possible deadlock scenarios, I chose 3 
classes to pre-initialize:
	- MethodHandle
	- MemberName
	- MethodHandleNatives

I placed the code right after compilers initialization because during 
method resolution for signature polymorphic intrinsics, compilation 
tasks are issued (see SystemDictionary::find_method_handle_intrinsic for 
details) and they are missed if compiler subsystem isn't ready yet.

Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke, 
vm.mlvm.testlist, octane.

Thanks!

Best regards,
Vladimir Ivanov

From gerard.ziemski at oracle.com  Tue Aug 20 10:39:26 2013
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Tue, 20 Aug 2013 12:39:26 -0500
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <5213335F.6060705@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
	<52124395.2000709@oracle.com> <5213335F.6060705@oracle.com>
Message-ID: <5213A9CE.5090208@oracle.com>


On 8/20/2013 4:14 AM, Dmitry Samersoff wrote:
>> 2. Why are we using the the "::" C++ name space before mach/pthread C
>> >APIs calls? I understand that you might be just following the existing
>> >pattern in the file, I'm just wondering if you, or anyone knows why.
> C++ :: means global scope and it solves naming conflict if you would
> have pthread_mach_thread_np() in your namespace and don't specify
> namespace explicitly.
>
> It's very good practice to always use :: for all os functions we call.

Is it (or should it be) part of Oracle's recommended coding guidelines?


cheers


From vladimir.kozlov at oracle.com  Tue Aug 20 11:00:17 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 Aug 2013 11:00:17 -0700
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213A1E9.1090002@oracle.com>
References: <5213A1E9.1090002@oracle.com>
Message-ID: <5213AEB1.9070802@oracle.com>

Looks fine to me.

You don't need /othervm in the test if you don't use any flags.

Thanks,
Vladimir

On 8/20/13 10:05 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
> 201 lines changed: 201 ins; 0 del; 0 mod;
>
> Some classes in j.l.invoke have circular dependencies between them which
> leads to deadlocks during class initialization when multiple threads
> exercise JSR292 functionality.
>
> JSR292 core classes are among "well-known" classes to VM and they are
> preloaded during VM startup (see
> SystemDictionary::initialize_preloaded_classes). However, it doesn't
> force preloaded classes to be initialized (doesn't execute static
> initializers). Thus, these classes should be explicitly pre-initialized
> in order to avoid deadlocks.
>
> Based on my observations of possible deadlock scenarios, I chose 3
> classes to pre-initialize:
>      - MethodHandle
>      - MemberName
>      - MethodHandleNatives
>
> I placed the code right after compilers initialization because during
> method resolution for signature polymorphic intrinsics, compilation
> tasks are issued (see SystemDictionary::find_method_handle_intrinsic for
> details) and they are missed if compiler subsystem isn't ready yet.
>
> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
> vm.mlvm.testlist, octane.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov

From vladimir.x.ivanov at oracle.com  Tue Aug 20 11:16:28 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 20 Aug 2013 22:16:28 +0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213AEB1.9070802@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213AEB1.9070802@oracle.com>
Message-ID: <5213B27C.2090808@oracle.com>

Vladimir,

Thanks for the review.

I specified /othervm, since I want to provoke a deadlock during JSR292 
core classes initialization. If the classes are already initialized, the 
test is meaningless.

Best regards,
Vladimir Ivanov

On 8/20/13 10:00 PM, Vladimir Kozlov wrote:
> Looks fine to me.
>
> You don't need /othervm in the test if you don't use any flags.
>
> Thanks,
> Vladimir
>
> On 8/20/13 10:05 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>
>> Some classes in j.l.invoke have circular dependencies between them which
>> leads to deadlocks during class initialization when multiple threads
>> exercise JSR292 functionality.
>>
>> JSR292 core classes are among "well-known" classes to VM and they are
>> preloaded during VM startup (see
>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>> force preloaded classes to be initialized (doesn't execute static
>> initializers). Thus, these classes should be explicitly pre-initialized
>> in order to avoid deadlocks.
>>
>> Based on my observations of possible deadlock scenarios, I chose 3
>> classes to pre-initialize:
>>      - MethodHandle
>>      - MemberName
>>      - MethodHandleNatives
>>
>> I placed the code right after compilers initialization because during
>> method resolution for signature polymorphic intrinsics, compilation
>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic for
>> details) and they are missed if compiler subsystem isn't ready yet.
>>
>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>> vm.mlvm.testlist, octane.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov

From vladimir.kozlov at oracle.com  Tue Aug 20 11:23:30 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 Aug 2013 11:23:30 -0700
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213B27C.2090808@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213AEB1.9070802@oracle.com>
	<5213B27C.2090808@oracle.com>
Message-ID: <5213B422.9090904@oracle.com>

On 8/20/13 11:16 AM, Vladimir Ivanov wrote:
> Vladimir,
>
> Thanks for the review.
>
> I specified /othervm, since I want to provoke a deadlock during JSR292
> core classes initialization. If the classes are already initialized, the
> test is meaningless.

Okay. Did you reproduce the failure with VM without fix and this test?

Thanks,
Vladimir

>
> Best regards,
> Vladimir Ivanov
>
> On 8/20/13 10:00 PM, Vladimir Kozlov wrote:
>> Looks fine to me.
>>
>> You don't need /othervm in the test if you don't use any flags.
>>
>> Thanks,
>> Vladimir
>>
>> On 8/20/13 10:05 AM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>
>>> Some classes in j.l.invoke have circular dependencies between them which
>>> leads to deadlocks during class initialization when multiple threads
>>> exercise JSR292 functionality.
>>>
>>> JSR292 core classes are among "well-known" classes to VM and they are
>>> preloaded during VM startup (see
>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>> force preloaded classes to be initialized (doesn't execute static
>>> initializers). Thus, these classes should be explicitly pre-initialized
>>> in order to avoid deadlocks.
>>>
>>> Based on my observations of possible deadlock scenarios, I chose 3
>>> classes to pre-initialize:
>>>      - MethodHandle
>>>      - MemberName
>>>      - MethodHandleNatives
>>>
>>> I placed the code right after compilers initialization because during
>>> method resolution for signature polymorphic intrinsics, compilation
>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic for
>>> details) and they are missed if compiler subsystem isn't ready yet.
>>>
>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>> vm.mlvm.testlist, octane.
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Vladimir Ivanov

From harold.seigel at oracle.com  Tue Aug 20 11:48:12 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Tue, 20 Aug 2013 14:48:12 -0400
Subject: Request for Review 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh
	fails on 64-bit solaris
In-Reply-To: <5212CA95.3090304@oracle.com>
References: <5203F024.9040006@oracle.com> <5212231A.7070704@oracle.com>
	<5212CA95.3090304@oracle.com>
Message-ID: <5213B9EC.8030709@oracle.com>

Hi David,

Thank you for the review.  I modified the test to work on both 32-bit 
Linux and OSX.  The test passed on 32-bit Linux but failed on OSX 
because the original fix for bug 7051189 had not been applied to OSX.  I 
entered a new bug for this, 8023393 
<https://jbs.oracle.com/bugs/browse/JDK-8023393>.

I am withdrawing this webrev and will send out a new webrev containing 
the fix for new bug 8023393 and a modified test that runs on 32-bit 
Linux and OSX, along with Solaris and 64-bit Linux.

Thanks!
Harold

On 8/19/2013 9:47 PM, David Holmes wrote:
> Hi Harold,
>
> Should this also apply to OSX? Why is it restricted to 64-bit?
>
> Thanks,
> David
>
> On 19/08/2013 11:52 PM, harold seigel wrote:
>> Hi,
>>
>> I'm resending this RFR because I did not get any reviewers the first
>> time.  If you have chance, please take a look.
>>
>> Thanks, Harold
>>
>> On 8/8/2013 3:23 PM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this change to fix bug 7121403.  The test was rewritten
>>> in Java and modified to properly determine when it is running on
>>> 64-bit Solaris.
>>>
>>> The fix was tested by running the new test on 32-bit Linux, Solaris
>>> Sparc, Solaris X86, and 64-bit Linux.
>>>
>>> webrev: http://cr.openjdk.java.net/~hseigel/bug_7121403/
>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_7121403/>
>>>
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7121403
>>>
>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-7121403
>>>
>>> Thanks! Harold
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130820/ad156661/attachment.html 

From coleen.phillimore at oracle.com  Tue Aug 20 12:02:32 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 20 Aug 2013 15:02:32 -0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213A1E9.1090002@oracle.com>
References: <5213A1E9.1090002@oracle.com>
Message-ID: <5213BD48.3030701@oracle.com>


Vladimir,

The code that you added is copied from the initialization code above.  I 
think they have a problem.  If initialization fails, there is a CHECK_0 
at the end of the call.  CHECK_0 returns JNI_OK to the caller, which 
goes ahead with the initialization.

Can you change all of these to CHECK_(JNI_ERR) so that the caller can 
deal with the error?  It would be good to see if the caller does the 
right thing with a JNI_ERR.

Otherwise, I think the code is fine if the initialization of these 
classes doesn't cause deadlocks in their new place.

Thanks,
Coleen

On 08/20/2013 01:05 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
> 201 lines changed: 201 ins; 0 del; 0 mod;
>
> Some classes in j.l.invoke have circular dependencies between them 
> which leads to deadlocks during class initialization when multiple 
> threads exercise JSR292 functionality.
>
> JSR292 core classes are among "well-known" classes to VM and they are 
> preloaded during VM startup (see 
> SystemDictionary::initialize_preloaded_classes). However, it doesn't 
> force preloaded classes to be initialized (doesn't execute static 
> initializers). Thus, these classes should be explicitly 
> pre-initialized in order to avoid deadlocks.
>
> Based on my observations of possible deadlock scenarios, I chose 3 
> classes to pre-initialize:
>     - MethodHandle
>     - MemberName
>     - MethodHandleNatives
>
> I placed the code right after compilers initialization because during 
> method resolution for signature polymorphic intrinsics, compilation 
> tasks are issued (see SystemDictionary::find_method_handle_intrinsic 
> for details) and they are missed if compiler subsystem isn't ready yet.
>
> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke, 
> vm.mlvm.testlist, octane.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov


From harold.seigel at oracle.com  Tue Aug 20 12:19:01 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Tue, 20 Aug 2013 15:19:01 -0400
Subject: Request for Review 8023393 Need to suppress info message if
	-Xcheck:jni used with libjsig.dylab on Mac OSX
Message-ID: <5213C125.8020703@oracle.com>

Hi,

Please review this small change to fix bug 8023393.  The fix was copied 
from the fix to os_linux.cpp for bug 7051189 and verified using the test 
included in the webrev.  The test was also run successfully on Solaris 
Sparc and X86 and Linux 64 and 32 bit platforms.  Additional testing was 
done using JPRT.

Webrev: http://cr.openjdk.java.net/~hseigel/bug_8023393/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_8023393/>

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

JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8023393

Thank you!
Harold

From vladimir.x.ivanov at oracle.com  Tue Aug 20 12:23:13 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 20 Aug 2013 23:23:13 +0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213B422.9090904@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213AEB1.9070802@oracle.com>
	<5213B27C.2090808@oracle.com> <5213B422.9090904@oracle.com>
Message-ID: <5213C221.5080105@oracle.com>

Yes, the test fails pretty reliably w/o the fix.

Best regards,
Vladimir Ivanov

On 8/20/13 10:23 PM, Vladimir Kozlov wrote:
> On 8/20/13 11:16 AM, Vladimir Ivanov wrote:
>> Vladimir,
>>
>> Thanks for the review.
>>
>> I specified /othervm, since I want to provoke a deadlock during JSR292
>> core classes initialization. If the classes are already initialized, the
>> test is meaningless.
>
> Okay. Did you reproduce the failure with VM without fix and this test?
>
> Thanks,
> Vladimir
>
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 8/20/13 10:00 PM, Vladimir Kozlov wrote:
>>> Looks fine to me.
>>>
>>> You don't need /othervm in the test if you don't use any flags.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 8/20/13 10:05 AM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>>
>>>> Some classes in j.l.invoke have circular dependencies between them
>>>> which
>>>> leads to deadlocks during class initialization when multiple threads
>>>> exercise JSR292 functionality.
>>>>
>>>> JSR292 core classes are among "well-known" classes to VM and they are
>>>> preloaded during VM startup (see
>>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>>> force preloaded classes to be initialized (doesn't execute static
>>>> initializers). Thus, these classes should be explicitly pre-initialized
>>>> in order to avoid deadlocks.
>>>>
>>>> Based on my observations of possible deadlock scenarios, I chose 3
>>>> classes to pre-initialize:
>>>>      - MethodHandle
>>>>      - MemberName
>>>>      - MethodHandleNatives
>>>>
>>>> I placed the code right after compilers initialization because during
>>>> method resolution for signature polymorphic intrinsics, compilation
>>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>>>> for
>>>> details) and they are missed if compiler subsystem isn't ready yet.
>>>>
>>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>>> vm.mlvm.testlist, octane.
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov

From coleen.phillimore at oracle.com  Tue Aug 20 12:25:19 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 20 Aug 2013 15:25:19 -0400
Subject: Request for Review 8023393 Need to suppress info message if
	-Xcheck:jni used with libjsig.dylab on Mac OSX
In-Reply-To: <5213C125.8020703@oracle.com>
References: <5213C125.8020703@oracle.com>
Message-ID: <5213C29F.5090306@oracle.com>


Looks good to me.  Much nicer as a Java program, and good to get bsd to 
pass the test also.
Thanks,
Coleen

On 08/20/2013 03:19 PM, harold seigel wrote:
> Hi,
>
> Please review this small change to fix bug 8023393.  The fix was 
> copied from the fix to os_linux.cpp for bug 7051189 and verified using 
> the test included in the webrev.  The test was also run successfully 
> on Solaris Sparc and X86 and Linux 64 and 32 bit platforms.  
> Additional testing was done using JPRT.
>
> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8023393/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8023393/>
>
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8023393
>
> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8023393
>
> Thank you!
> Harold


From chris.plummer at oracle.com  Tue Aug 20 12:33:23 2013
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 20 Aug 2013 12:33:23 -0700
Subject: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on platforms
	if NMT detail is not supported
Message-ID: <5213C483.1060102@oracle.com>

https://jbs.oracle.com/bugs/browse/JDK-8020829
http://cr.openjdk.java.net/~cjplummer/8020829/webrev-03/

On some platforms, NMT detail is not supported, and this was causing 
some jtreg tests to fail. These tests now query a new WhiteBox API to 
see if NMT detail is supported, and now behave properly if it is not 
supported.

I also fixed #ifdef INCLUDE_NMT in whitebox.cpp that should instead be 
#if INCLUDE_NMT. The source within the #if is now properly excluded from 
minimal VM builds.

The addition of Platform.isArm() is to support changes in closed source.

Testing was done using the existing NMT tests, verifying that they now 
pass on platforms where NMT detail is not supported, and still pass on 
platforms where NMT detail is supported. A jprt job is currently in the 
queue to run all NMT jtreg tests on all platforms supported by jprt.

Thanks!

Chris Plummer

From vladimir.kozlov at oracle.com  Tue Aug 20 13:07:28 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 Aug 2013 13:07:28 -0700
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213C221.5080105@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213AEB1.9070802@oracle.com>
	<5213B27C.2090808@oracle.com> <5213B422.9090904@oracle.com>
	<5213C221.5080105@oracle.com>
Message-ID: <5213CC80.9090907@oracle.com>

On 8/20/13 12:23 PM, Vladimir Ivanov wrote:
> Yes, the test fails pretty reliably w/o the fix.

Good. And Coleen has valid point about CHECK_0.

Thanks,
Vladimir


>
> Best regards,
> Vladimir Ivanov
>
> On 8/20/13 10:23 PM, Vladimir Kozlov wrote:
>> On 8/20/13 11:16 AM, Vladimir Ivanov wrote:
>>> Vladimir,
>>>
>>> Thanks for the review.
>>>
>>> I specified /othervm, since I want to provoke a deadlock during JSR292
>>> core classes initialization. If the classes are already initialized, the
>>> test is meaningless.
>>
>> Okay. Did you reproduce the failure with VM without fix and this test?
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 8/20/13 10:00 PM, Vladimir Kozlov wrote:
>>>> Looks fine to me.
>>>>
>>>> You don't need /othervm in the test if you don't use any flags.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 8/20/13 10:05 AM, Vladimir Ivanov wrote:
>>>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>>>
>>>>> Some classes in j.l.invoke have circular dependencies between them
>>>>> which
>>>>> leads to deadlocks during class initialization when multiple threads
>>>>> exercise JSR292 functionality.
>>>>>
>>>>> JSR292 core classes are among "well-known" classes to VM and they are
>>>>> preloaded during VM startup (see
>>>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>>>> force preloaded classes to be initialized (doesn't execute static
>>>>> initializers). Thus, these classes should be explicitly
>>>>> pre-initialized
>>>>> in order to avoid deadlocks.
>>>>>
>>>>> Based on my observations of possible deadlock scenarios, I chose 3
>>>>> classes to pre-initialize:
>>>>>      - MethodHandle
>>>>>      - MemberName
>>>>>      - MethodHandleNatives
>>>>>
>>>>> I placed the code right after compilers initialization because during
>>>>> method resolution for signature polymorphic intrinsics, compilation
>>>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>>>>> for
>>>>> details) and they are missed if compiler subsystem isn't ready yet.
>>>>>
>>>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>>>> vm.mlvm.testlist, octane.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov

From ioi.lam at oracle.com  Tue Aug 20 14:11:37 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 20 Aug 2013 14:11:37 -0700
Subject: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even
	when BUILD_WIN_SA != 1
Message-ID: <5213DB89.6080705@oracle.com>

|Please review a very small fix:||
||
||http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/||
||
||Bug: make/windows/build_vm_def.sh takes too long even when 
BUILD_WIN_SA != 1||
||
||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023406||
||    https://jbs.oracle.com/bugs/browse/JDK-8023406||
||
||Summary of fix:||
||
||    Reduce Windows build time to improve developer productivity.||
||
||    If BUILD_WIN_SA != 1, don't bother to generate vm.def, whose sole ||
||    purpose is for SA to determine the type information of C++ objects.||
||
||    Instead, this rather eye-catching warning is printed, and 10 seconds||
||    are saved in the build cycle.||
||
||        ***||
||        *** Not building SA: BUILD_WIN_SA != 1||
||        *** C++ Vtables NOT included in vm.def||
||        *** This jvm.dll will NOT work properly with SA.||
||        ***||
||        *** When in doubt, set BUILD_WIN_SA=1, clean and rebuild.||
||        ***||
||
||    This does not affect JPRT -- JPRT always sets BUILD_WIN_SA=1.||
||
||Result: ||
||
||    Touch 1 .cpp file; rebuild: Total time is reduced 15 seconds -> 5 
seconds.||
||
||Tests:||
||
     [0] Manual testing with both create.bat (IDE build) and build.bat
         VS 2008 + VS2010
||    [1] JPRT (windows.* only)||
||    [2] I built a jvm.dll without BUILD_WIN_SA=0, and it ran Eclipsed 
without||
||        any problem.||
||
||Thanks||
||- Ioi|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130820/19baf340/attachment-0001.html 

From mandy.chung at oracle.com  Tue Aug 20 14:52:23 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 20 Aug 2013 14:52:23 -0700
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com>
References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com>
	<8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com>
Message-ID: <5213E517.5000106@oracle.com>


On 8/20/2013 5:38 AM, Staffan Larsen wrote:
> That doesn't make a lot of sense to me. Why would a pool have undefined values?
> The Metaspace pool has no max value (unless you specify -XX:MaxMetaspaceSize=), thus undefined.
>
>> If a subset of pools have undefined values why report completely fallacious values of -1?
> The javadoc for MemoryUsage says getMax() returns -1 if the maximum memory size is undefined.

Yes the spec allows implementation of memory pools with undefined max.  
"used" and "committed" must have a value and the "committed" memory is 
guaranteed to be available for the VM to use.  "max" will give an idea 
of the upper bound how much memory can be allocated from it; however, 
there is no guarantee that amount of memory is available for the VM.

>> It also isn't clear how this relates to the "committed" value in the failure. What gets reported now?
> I guess there can still be a committed value even if we don't have a max value for how much we might commit in the future: used <= committed <= max.

The MemoryUsage constructor throws IAE if committed > max if max is 
defined.  Perhaps it would be better if max should be Long.MAX_VALUE if 
undefined (a different issue than this bug).

Mandy

> /Staffan
>
>> Thanks,
>> David
>>
>>> Thanks,
>>> Vladimir
>>>


From vladimir.x.ivanov at oracle.com  Tue Aug 20 14:55:54 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 21 Aug 2013 01:55:54 +0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213BD48.3030701@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213BD48.3030701@oracle.com>
Message-ID: <5213E5EA.8000504@oracle.com>

Coleen,

Thank you for the review.
It doesn't cause a deadlock anymore because class loading is guaranteed 
to be performed in singe-threaded mode.

Regarding CHECK_0 -> CHECK_(JNI_ERR) change you propose, there's one 
problem. All pending exceptions are fatal right now: even if it returns 
JNI_OK, there's an ExceptionMark on the stack which crashes VM if any 
pending exceptions are present.

Considering that JNI_CreateJavaVM uses Thread::create_vm and failure 
during VM initialization can crash the whole app, I don't think such 
behavior is correct.

So, I have 2 questions here:
	1) what behavior do we prefer?
	2) if we want to change current behavior, doesn't it deserve a separate 
fix?

Best regards,
Vladimir Ivanov

On 8/20/13 11:02 PM, Coleen Phillimore wrote:
>
> Vladimir,
>
> The code that you added is copied from the initialization code above.  I
> think they have a problem.  If initialization fails, there is a CHECK_0
> at the end of the call.  CHECK_0 returns JNI_OK to the caller, which
> goes ahead with the initialization.
>
> Can you change all of these to CHECK_(JNI_ERR) so that the caller can
> deal with the error?  It would be good to see if the caller does the
> right thing with a JNI_ERR.
>
> Otherwise, I think the code is fine if the initialization of these
> classes doesn't cause deadlocks in their new place.
>
> Thanks,
> Coleen
>
> On 08/20/2013 01:05 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>
>> Some classes in j.l.invoke have circular dependencies between them
>> which leads to deadlocks during class initialization when multiple
>> threads exercise JSR292 functionality.
>>
>> JSR292 core classes are among "well-known" classes to VM and they are
>> preloaded during VM startup (see
>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>> force preloaded classes to be initialized (doesn't execute static
>> initializers). Thus, these classes should be explicitly
>> pre-initialized in order to avoid deadlocks.
>>
>> Based on my observations of possible deadlock scenarios, I chose 3
>> classes to pre-initialize:
>>     - MethodHandle
>>     - MemberName
>>     - MethodHandleNatives
>>
>> I placed the code right after compilers initialization because during
>> method resolution for signature polymorphic intrinsics, compilation
>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>> for details) and they are missed if compiler subsystem isn't ready yet.
>>
>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>> vm.mlvm.testlist, octane.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>

From daniel.daugherty at oracle.com  Tue Aug 20 15:01:15 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 20 Aug 2013 16:01:15 -0600
Subject: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even
	when BUILD_WIN_SA != 1
In-Reply-To: <5213DB89.6080705@oracle.com>
References: <5213DB89.6080705@oracle.com>
Message-ID: <5213E72B.8040309@oracle.com>

Adding in Serviceability Team since the SA belongs to them.

Dan


On 8/20/13 3:11 PM, Ioi Lam wrote:
> |Please review a very small fix:||
> ||
> ||http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/||
> ||
> ||Bug: make/windows/build_vm_def.sh takes too long even when 
> BUILD_WIN_SA != 1||
> ||
> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023406||
> ||https://jbs.oracle.com/bugs/browse/JDK-8023406||
> ||
> ||Summary of fix:||
> ||
> ||    Reduce Windows build time to improve developer productivity.||
> ||
> ||    If BUILD_WIN_SA != 1, don't bother to generate vm.def, whose sole ||
> ||    purpose is for SA to determine the type information of C++ 
> objects.||
> ||
> ||    Instead, this rather eye-catching warning is printed, and 10 
> seconds||
> ||    are saved in the build cycle.||
> ||
> ||        ***||
> ||        *** Not building SA: BUILD_WIN_SA != 1||
> ||        *** C++ Vtables NOT included in vm.def||
> ||        *** This jvm.dll will NOT work properly with SA.||
> ||        ***||
> ||        *** When in doubt, set BUILD_WIN_SA=1, clean and rebuild.||
> ||        ***||
> ||
> ||    This does not affect JPRT -- JPRT always sets BUILD_WIN_SA=1.||
> ||
> ||Result: ||
> ||
> ||    Touch 1 .cpp file; rebuild: Total time is reduced 15 seconds -> 
> 5 seconds.||
> ||
> ||Tests:||
> ||
>     [0] Manual testing with both create.bat (IDE build) and build.bat
>         VS 2008 + VS2010
> ||    [1] JPRT (windows.* only)||
> ||    [2] I built a jvm.dll without BUILD_WIN_SA=0, and it ran 
> Eclipsed without||
> ||        any problem.||
> ||
> ||Thanks||
> ||- Ioi| 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130820/7c916b1d/attachment.html 

From mikhailo.seledtsov at oracle.com  Tue Aug 20 15:07:40 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Tue, 20 Aug 2013 18:07:40 -0400
Subject: RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh failed
	- round 2
In-Reply-To: <5212ED9E.7090405@oracle.com>
References: <52125ACF.9050803@oracle.com> <5212D177.8070907@oracle.com>
	<00a501ce9d5b$2f5bc050$8e1340f0$@oracle.com>
	<5212ED9E.7090405@oracle.com>
Message-ID: <5213E8AC.4000100@oracle.com>

Gary, David, Christian,
    Thank you for the review.

Here is my feedback:
  On (1), the missing @run tag, I will make the change before the 
check-in. I assume the change is minor enough not to require posting new 
webrev.

  On (3), I will follow Christian's recommendation, since David says he 
will not push it. My personal view on this is to keep the test code to 
the substance of the test, and leave cleanup to the framework. As for 
running  JTREG tests outside of the framework, I ofter do that; I 
usually wrap the tests into a script that deletes or renames JT* folders 
before running the tests.

  On (2), the use of 'jar' tool from compile vs test JDK 
(JDKToolFinder.getJDKTool("jar")). I have discussed this with Christian. 
Christian says that there is a change on the way to fix the gedJdkTool() 
API. The new  behavior of  this method will attempt to find the tool in 
the Test JDK first; if not found, it will use the tool from the compile 
JDK. Given this, and if no one has additional objections, I am inclined 
not to make changes to this section of the test.

To recap, if I do not receive additional comments or objections, I will 
make change (1) and send it on the way to check in.

Thank you,
Misha

On 8/20/2013 12:16 AM, David Holmes wrote:
> Hi Christian,
>
> On 20/08/2013 2:10 PM, Christian Tornqvist wrote:
>> Hi David,
>>
>>> 1. Missing @run tag
>>
>> The default action (when there is no @compile or @run tag ) of jtreg 
>> is '@run main Test.java'
>
> Okay, but there have been a few issues lately with misconfigured tags 
> so I think it preferable to be explicit.
>
>>> 3. Not new with your change, but the unpacked files don't get 
>>> cleaned up.
>>
>> Jtreg will clean up the scratch directory when the test has passed, 
>> this not something the tests should do themselves
>
> I see we are relying on jtreg to do the cleanup here, but I like tests 
> that can be run outside of jtreg too and not cause problems and/or a 
> mess. But I won't push it. :)
>
> Thanks,
> David
>
>> Thanks,
>> Christian
>>
>> -----Original Message-----
>> From: hotspot-runtime-dev-bounces at openjdk.java.net 
>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of 
>> David Holmes
>> Sent: Monday, August 19, 2013 10:16 PM
>> To: Mikhailo Seledtsov
>> Cc: hotspot-runtime-dev
>> Subject: Re: RFR (M) : JDK-8016029 : test 
>> runtime/6878713/Test6878713.sh failed - round 2
>>
>> Hi Misha,
>>
>> I have a couple of issues with this.
>>
>> 1. Missing @run tag
>>
>> 2. The shell script uses the COMPILEJDK to find the jar tool, but you 
>> are using JDKToolFinder which uses the TESTJDK - which means your 
>> test will be limited to running only on a full JDK (not a JRE). I 
>> thought the testlibrary supported using either the test-jdk or the 
>> compile-jdk but I don't see that now. :(
>>
>> 3. Not new with your change, but the unpacked files don't get cleaned 
>> up.
>>
>> Thanks,
>> David
>>
>> On 20/08/2013 3:50 AM, Mikhailo Seledtsov wrote:
>>> This is a round 2 review for this fix.
>>> Please review.
>>>
>>> Original review request (dated 16-July-2013) with the same subject was:
>>> "
>>> Please review this test fix. The change is a fix for the original bug,
>>> plus an update to the test condition to reflect new JVM behavior and a
>>> rewrite of an sh script test in Java.
>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8016029
>>> (Old) Webrev:
>>> http://cr.openjdk.java.net/~mseledtsov/6878713/webrev.00/
>>> <http://cr.openjdk.java.net/%7Emseledtsov/6878713/webrev.00/>
>>> "
>>>
>>>
>>> Change since last round of review:
>>>       JVM run-time technical leadership has made a decision to keep the
>>> testcase.jar until a long-term solution is in place for handling "Java
>>> assembler"-based and byte-code-based test cases.
>>>
>>> Here is the updated webrev and comments:
>>>       Webrev: http://cr.openjdk.java.net/~mseledtsov/8016029/webrev.01/
>>> <http://cr.openjdk.java.net/%7Emseledtsov/8016029/webrev.01/>
>>>       Testing: JPRT run for this test
>>> (2013-08-19-154813.mseledtsov.bugFixing01-hotspot-rt)
>>>
>>> Here are original notes:
>>> - the original behavior of the VM in this test case has changed, and
>>> the expected error message has changed as well. There is an extensive
>>> amount of information about this in the original bug, posted by Dan.
>>> The change was introduced in change-set: 4876:f75faf51e8c4 by Harold.
>>> Checking for the old expected messages has been removed from the test.
>>> This change is for JDK8 and forward, and no back-ports planned.
>>>
>>> - the flag -XX:+IgnoreUnrecognizedVMOptions has been removed to avoid
>>> masking a potential problem. If VM drops support for any of XX flags
>>> used in this test, it is better to know about it right away rather
>>> than mask it and silently pass/ignore.
>>>
>>> - the flag -XX:+PrintCommandLineFlags has been removed; if this
>>> information is desired, IMO it should be triggered either by a verbose
>>> mode of JTREG tools, or by hand, not by individual test(s).
>>>
>>> Round 2 notes:
>>> - the shell script has been replaced by Java
>>>
>>> - test has been moved to a new location, moving away from using bug
>>> numbers to using functional categories for test sub-folders
>>>
>>>
>>> Misha
>>


From coleen.phillimore at oracle.com  Tue Aug 20 15:24:56 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 20 Aug 2013 18:24:56 -0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213E5EA.8000504@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213BD48.3030701@oracle.com>
	<5213E5EA.8000504@oracle.com>
Message-ID: <5213ECB8.7030503@oracle.com>



Vladimir,

You are right, it's broken.  Calvin is working on a similar issue in bug 
https://jbs.oracle.com/bugs/browse/JDK-8020675.

I think you should check in your code and we'll fix all the 
CHECK_0/EXCEPTION_MARK problems at once.

Thanks for checking this out.
Coleen

On 08/20/2013 05:55 PM, Vladimir Ivanov wrote:
> Coleen,
>
> Thank you for the review.
> It doesn't cause a deadlock anymore because class loading is 
> guaranteed to be performed in singe-threaded mode.
>
> Regarding CHECK_0 -> CHECK_(JNI_ERR) change you propose, there's one 
> problem. All pending exceptions are fatal right now: even if it 
> returns JNI_OK, there's an ExceptionMark on the stack which crashes VM 
> if any pending exceptions are present.
>
> Considering that JNI_CreateJavaVM uses Thread::create_vm and failure 
> during VM initialization can crash the whole app, I don't think such 
> behavior is correct.
>
> So, I have 2 questions here:
>     1) what behavior do we prefer?
>     2) if we want to change current behavior, doesn't it deserve a 
> separate fix?
>
> Best regards,
> Vladimir Ivanov
>
> On 8/20/13 11:02 PM, Coleen Phillimore wrote:
>>
>> Vladimir,
>>
>> The code that you added is copied from the initialization code above.  I
>> think they have a problem.  If initialization fails, there is a CHECK_0
>> at the end of the call.  CHECK_0 returns JNI_OK to the caller, which
>> goes ahead with the initialization.
>>
>> Can you change all of these to CHECK_(JNI_ERR) so that the caller can
>> deal with the error?  It would be good to see if the caller does the
>> right thing with a JNI_ERR.
>>
>> Otherwise, I think the code is fine if the initialization of these
>> classes doesn't cause deadlocks in their new place.
>>
>> Thanks,
>> Coleen
>>
>> On 08/20/2013 01:05 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>
>>> Some classes in j.l.invoke have circular dependencies between them
>>> which leads to deadlocks during class initialization when multiple
>>> threads exercise JSR292 functionality.
>>>
>>> JSR292 core classes are among "well-known" classes to VM and they are
>>> preloaded during VM startup (see
>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>> force preloaded classes to be initialized (doesn't execute static
>>> initializers). Thus, these classes should be explicitly
>>> pre-initialized in order to avoid deadlocks.
>>>
>>> Based on my observations of possible deadlock scenarios, I chose 3
>>> classes to pre-initialize:
>>>     - MethodHandle
>>>     - MemberName
>>>     - MethodHandleNatives
>>>
>>> I placed the code right after compilers initialization because during
>>> method resolution for signature polymorphic intrinsics, compilation
>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>>> for details) and they are missed if compiler subsystem isn't ready yet.
>>>
>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>> vm.mlvm.testlist, octane.
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>


From coleen.phillimore at oracle.com  Tue Aug 20 15:35:22 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 20 Aug 2013 18:35:22 -0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213ECB8.7030503@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213BD48.3030701@oracle.com>
	<5213E5EA.8000504@oracle.com> <5213ECB8.7030503@oracle.com>
Message-ID: <5213EF2A.2090203@oracle.com>


On 08/20/2013 06:24 PM, Coleen Phillimore wrote:
>
>
> Vladimir,
>
> You are right, it's broken.  Calvin is working on a similar issue in 
> bug https://jbs.oracle.com/bugs/browse/JDK-8020675.

Reading more, I think Calvin's issue is similar but different.  I will 
file a new bug for the Threads::create_vm() EXCEPTION_MARK.

Coleen

>
> I think you should check in your code and we'll fix all the 
> CHECK_0/EXCEPTION_MARK problems at once.
>
> Thanks for checking this out.
> Coleen
>
> On 08/20/2013 05:55 PM, Vladimir Ivanov wrote:
>> Coleen,
>>
>> Thank you for the review.
>> It doesn't cause a deadlock anymore because class loading is 
>> guaranteed to be performed in singe-threaded mode.
>>
>> Regarding CHECK_0 -> CHECK_(JNI_ERR) change you propose, there's one 
>> problem. All pending exceptions are fatal right now: even if it 
>> returns JNI_OK, there's an ExceptionMark on the stack which crashes 
>> VM if any pending exceptions are present.
>>
>> Considering that JNI_CreateJavaVM uses Thread::create_vm and failure 
>> during VM initialization can crash the whole app, I don't think such 
>> behavior is correct.
>>
>> So, I have 2 questions here:
>>     1) what behavior do we prefer?
>>     2) if we want to change current behavior, doesn't it deserve a 
>> separate fix?
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 8/20/13 11:02 PM, Coleen Phillimore wrote:
>>>
>>> Vladimir,
>>>
>>> The code that you added is copied from the initialization code 
>>> above.  I
>>> think they have a problem.  If initialization fails, there is a CHECK_0
>>> at the end of the call.  CHECK_0 returns JNI_OK to the caller, which
>>> goes ahead with the initialization.
>>>
>>> Can you change all of these to CHECK_(JNI_ERR) so that the caller can
>>> deal with the error?  It would be good to see if the caller does the
>>> right thing with a JNI_ERR.
>>>
>>> Otherwise, I think the code is fine if the initialization of these
>>> classes doesn't cause deadlocks in their new place.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 08/20/2013 01:05 PM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>>
>>>> Some classes in j.l.invoke have circular dependencies between them
>>>> which leads to deadlocks during class initialization when multiple
>>>> threads exercise JSR292 functionality.
>>>>
>>>> JSR292 core classes are among "well-known" classes to VM and they are
>>>> preloaded during VM startup (see
>>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>>> force preloaded classes to be initialized (doesn't execute static
>>>> initializers). Thus, these classes should be explicitly
>>>> pre-initialized in order to avoid deadlocks.
>>>>
>>>> Based on my observations of possible deadlock scenarios, I chose 3
>>>> classes to pre-initialize:
>>>>     - MethodHandle
>>>>     - MemberName
>>>>     - MethodHandleNatives
>>>>
>>>> I placed the code right after compilers initialization because during
>>>> method resolution for signature polymorphic intrinsics, compilation
>>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>>>> for details) and they are missed if compiler subsystem isn't ready 
>>>> yet.
>>>>
>>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>>> vm.mlvm.testlist, octane.
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>
>


From daniel.daugherty at oracle.com  Tue Aug 20 17:02:24 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Wed, 21 Aug 2013 00:02:24 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8023287: HOTSPOT_BUILD_COMPILER needs to
	support "Sun Studio 12u3"
Message-ID: <20130821000226.151F248A17@hg.openjdk.java.net>

Changeset: 9d6c9b0a8f15
Author:    dcubed
Date:      2013-08-20 13:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9d6c9b0a8f15

8023287: HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3"
Summary: Recognize 0x5120 as "Sun Studio 12u3".
Reviewed-by: dholmes, coleenp

! src/share/vm/runtime/vm_version.cpp


From david.holmes at oracle.com  Tue Aug 20 17:48:23 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 10:48:23 +1000
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213EF2A.2090203@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213BD48.3030701@oracle.com>
	<5213E5EA.8000504@oracle.com> <5213ECB8.7030503@oracle.com>
	<5213EF2A.2090203@oracle.com>
Message-ID: <52140E57.8030409@oracle.com>

On 21/08/2013 8:35 AM, Coleen Phillimore wrote:
>
> On 08/20/2013 06:24 PM, Coleen Phillimore wrote:
>>
>>
>> Vladimir,
>>
>> You are right, it's broken.  Calvin is working on a similar issue in
>> bug https://jbs.oracle.com/bugs/browse/JDK-8020675.
>
> Reading more, I think Calvin's issue is similar but different.  I will
> file a new bug for the Threads::create_vm() EXCEPTION_MARK.

I think the intent is that we never, ever expect to get any exceptions 
during VM initialization unless we have a significant bug. The 
EXCEPTION_MARK detects that bug in debug builds.

I have a vague recollection of the CHECK_0 "bug" being discussed when I 
was in runtime.

David

> Coleen
>
>>
>> I think you should check in your code and we'll fix all the
>> CHECK_0/EXCEPTION_MARK problems at once.
>>
>> Thanks for checking this out.
>> Coleen
>>
>> On 08/20/2013 05:55 PM, Vladimir Ivanov wrote:
>>> Coleen,
>>>
>>> Thank you for the review.
>>> It doesn't cause a deadlock anymore because class loading is
>>> guaranteed to be performed in singe-threaded mode.
>>>
>>> Regarding CHECK_0 -> CHECK_(JNI_ERR) change you propose, there's one
>>> problem. All pending exceptions are fatal right now: even if it
>>> returns JNI_OK, there's an ExceptionMark on the stack which crashes
>>> VM if any pending exceptions are present.
>>>
>>> Considering that JNI_CreateJavaVM uses Thread::create_vm and failure
>>> during VM initialization can crash the whole app, I don't think such
>>> behavior is correct.
>>>
>>> So, I have 2 questions here:
>>>     1) what behavior do we prefer?
>>>     2) if we want to change current behavior, doesn't it deserve a
>>> separate fix?
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 8/20/13 11:02 PM, Coleen Phillimore wrote:
>>>>
>>>> Vladimir,
>>>>
>>>> The code that you added is copied from the initialization code
>>>> above.  I
>>>> think they have a problem.  If initialization fails, there is a CHECK_0
>>>> at the end of the call.  CHECK_0 returns JNI_OK to the caller, which
>>>> goes ahead with the initialization.
>>>>
>>>> Can you change all of these to CHECK_(JNI_ERR) so that the caller can
>>>> deal with the error?  It would be good to see if the caller does the
>>>> right thing with a JNI_ERR.
>>>>
>>>> Otherwise, I think the code is fine if the initialization of these
>>>> classes doesn't cause deadlocks in their new place.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 08/20/2013 01:05 PM, Vladimir Ivanov wrote:
>>>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>>>
>>>>> Some classes in j.l.invoke have circular dependencies between them
>>>>> which leads to deadlocks during class initialization when multiple
>>>>> threads exercise JSR292 functionality.
>>>>>
>>>>> JSR292 core classes are among "well-known" classes to VM and they are
>>>>> preloaded during VM startup (see
>>>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>>>> force preloaded classes to be initialized (doesn't execute static
>>>>> initializers). Thus, these classes should be explicitly
>>>>> pre-initialized in order to avoid deadlocks.
>>>>>
>>>>> Based on my observations of possible deadlock scenarios, I chose 3
>>>>> classes to pre-initialize:
>>>>>     - MethodHandle
>>>>>     - MemberName
>>>>>     - MethodHandleNatives
>>>>>
>>>>> I placed the code right after compilers initialization because during
>>>>> method resolution for signature polymorphic intrinsics, compilation
>>>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>>>>> for details) and they are missed if compiler subsystem isn't ready
>>>>> yet.
>>>>>
>>>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>>>> vm.mlvm.testlist, octane.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>
>>
>

From david.holmes at oracle.com  Tue Aug 20 17:52:33 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 10:52:33 +1000
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213A1E9.1090002@oracle.com>
References: <5213A1E9.1090002@oracle.com>
Message-ID: <52140F51.9050103@oracle.com>

Hi Vladimir,

The initialization code location looks good to me.

I presume the shutdown hook in the test (another reason this needs to be 
othervm!) is to see a dump via ctrl-C if there is a hang?

David

On 21/08/2013 3:05 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
> 201 lines changed: 201 ins; 0 del; 0 mod;
>
> Some classes in j.l.invoke have circular dependencies between them which
> leads to deadlocks during class initialization when multiple threads
> exercise JSR292 functionality.
>
> JSR292 core classes are among "well-known" classes to VM and they are
> preloaded during VM startup (see
> SystemDictionary::initialize_preloaded_classes). However, it doesn't
> force preloaded classes to be initialized (doesn't execute static
> initializers). Thus, these classes should be explicitly pre-initialized
> in order to avoid deadlocks.
>
> Based on my observations of possible deadlock scenarios, I chose 3
> classes to pre-initialize:
>      - MethodHandle
>      - MemberName
>      - MethodHandleNatives
>
> I placed the code right after compilers initialization because during
> method resolution for signature polymorphic intrinsics, compilation
> tasks are issued (see SystemDictionary::find_method_handle_intrinsic for
> details) and they are missed if compiler subsystem isn't ready yet.
>
> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
> vm.mlvm.testlist, octane.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov

From david.holmes at oracle.com  Tue Aug 20 18:09:22 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 11:09:22 +1000
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <5213A9CE.5090208@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
	<52124395.2000709@oracle.com> <5213335F.6060705@oracle.com>
	<5213A9CE.5090208@oracle.com>
Message-ID: <52141342.301@oracle.com>

On 21/08/2013 3:39 AM, Gerard Ziemski wrote:
>
> On 8/20/2013 4:14 AM, Dmitry Samersoff wrote:
>>> 2. Why are we using the the "::" C++ name space before mach/pthread C
>>> >APIs calls? I understand that you might be just following the existing
>>> >pattern in the file, I'm just wondering if you, or anyone knows why.
>> C++ :: means global scope and it solves naming conflict if you would
>> have pthread_mach_thread_np() in your namespace and don't specify
>> namespace explicitly.
>>
>> It's very good practice to always use :: for all os functions we call.
>
> Is it (or should it be) part of Oracle's recommended coding guidelines?

It is a two edged sword. There have been bugs where the we call the 
global function instead of a local one, and local instead of a global. 
Used to be quite complex/confusing with the hpi interface - too many 
open/close/read/write methods.

Personally I find it totally unnecessary and distracting on things like 
pthreads library calls. We should never define our own methods with the 
same names as those.

Cheers,
David

>
> cheers
>

From david.holmes at oracle.com  Tue Aug 20 18:15:31 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 11:15:31 +1000
Subject: Request for Review 8023393 Need to suppress info message if
	-Xcheck:jni used with libjsig.dylab on Mac OSX
In-Reply-To: <5213C125.8020703@oracle.com>
References: <5213C125.8020703@oracle.com>
Message-ID: <521414B3.6040903@oracle.com>

Looks good!

Thanks,
David

On 21/08/2013 5:19 AM, harold seigel wrote:
> Hi,
>
> Please review this small change to fix bug 8023393.  The fix was copied
> from the fix to os_linux.cpp for bug 7051189 and verified using the test
> included in the webrev.  The test was also run successfully on Solaris
> Sparc and X86 and Linux 64 and 32 bit platforms.  Additional testing was
> done using JPRT.
>
> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8023393/
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8023393/>
>
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8023393
>
> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8023393
>
> Thank you!
> Harold

From david.holmes at oracle.com  Tue Aug 20 18:26:20 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 11:26:20 +1000
Subject: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on platforms
	if NMT detail is not supported
In-Reply-To: <5213C483.1060102@oracle.com>
References: <5213C483.1060102@oracle.com>
Message-ID: <5214173C.7000806@oracle.com>

Hi Chris,

On 21/08/2013 5:33 AM, Chris Plummer wrote:
> https://jbs.oracle.com/bugs/browse/JDK-8020829
> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-03/
>
> On some platforms, NMT detail is not supported, and this was causing
> some jtreg tests to fail. These tests now query a new WhiteBox API to
> see if NMT detail is supported, and now behave properly if it is not
> supported.

Okay.

> I also fixed #ifdef INCLUDE_NMT in whitebox.cpp that should instead be
> #if INCLUDE_NMT. The source within the #if is now properly excluded from
> minimal VM builds.

Okay.

> The addition of Platform.isArm() is to support changes in closed source.

I hate seeing these kinds of methods. Add a new platform, add a new 
method - yuck! :(

We could just use getOsArch().toLowerCase().startsWith("arm") directly.

I'd even prefer to see:

boolean isArch(String arch) {
   return osArch.toLowerCase().startsWith(arch.toLowerCase());
}

and similarly for the OS - but that is going beyond this fix :)

Thanks,
David

> Testing was done using the existing NMT tests, verifying that they now
> pass on platforms where NMT detail is not supported, and still pass on
> platforms where NMT detail is supported. A jprt job is currently in the
> queue to run all NMT jtreg tests on all platforms supported by jprt.
>
> Thanks!
>
> Chris Plummer

From chris.plummer at oracle.com  Tue Aug 20 18:47:37 2013
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 20 Aug 2013 18:47:37 -0700
Subject: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on platforms
	if NMT detail is not supported
In-Reply-To: <5214173C.7000806@oracle.com>
References: <5213C483.1060102@oracle.com> <5214173C.7000806@oracle.com>
Message-ID: <52141C39.3070509@oracle.com>

On 8/20/13 6:26 PM, David Holmes wrote:
> Hi Chris,
>
> On 21/08/2013 5:33 AM, Chris Plummer wrote:
>> https://jbs.oracle.com/bugs/browse/JDK-8020829
>> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-03/
>>
>> On some platforms, NMT detail is not supported, and this was causing
>> some jtreg tests to fail. These tests now query a new WhiteBox API to
>> see if NMT detail is supported, and now behave properly if it is not
>> supported.
>
> Okay.
>
>> I also fixed #ifdef INCLUDE_NMT in whitebox.cpp that should instead be
>> #if INCLUDE_NMT. The source within the #if is now properly excluded from
>> minimal VM builds.
>
> Okay.
>
>> The addition of Platform.isArm() is to support changes in closed source.
>
> I hate seeing these kinds of methods. Add a new platform, add a new 
> method - yuck! :(
>
> We could just use getOsArch().toLowerCase().startsWith("arm") directly.
>
> I'd even prefer to see:
>
> boolean isArch(String arch) {
>   return osArch.toLowerCase().startsWith(arch.toLowerCase());
> }
>
> and similarly for the OS - but that is going beyond this fix :)
I'm not particularly tied to any specific way of doing this. I can do 
either of the above if you wish. Just let me know your preference.

Chris
>
> Thanks,
> David
>
>> Testing was done using the existing NMT tests, verifying that they now
>> pass on platforms where NMT detail is not supported, and still pass on
>> platforms where NMT detail is supported. A jprt job is currently in the
>> queue to run all NMT jtreg tests on all platforms supported by jprt.
>>
>> Thanks!
>>
>> Chris Plummer


From david.holmes at oracle.com  Tue Aug 20 18:55:15 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 11:55:15 +1000
Subject: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on platforms
	if NMT detail is not supported
In-Reply-To: <52141C39.3070509@oracle.com>
References: <5213C483.1060102@oracle.com> <5214173C.7000806@oracle.com>
	<52141C39.3070509@oracle.com>
Message-ID: <52141E03.3060003@oracle.com>

On 21/08/2013 11:47 AM, Chris Plummer wrote:
> On 8/20/13 6:26 PM, David Holmes wrote:
>> Hi Chris,
>>
>> On 21/08/2013 5:33 AM, Chris Plummer wrote:
>>> https://jbs.oracle.com/bugs/browse/JDK-8020829
>>> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-03/
>>>
>>> On some platforms, NMT detail is not supported, and this was causing
>>> some jtreg tests to fail. These tests now query a new WhiteBox API to
>>> see if NMT detail is supported, and now behave properly if it is not
>>> supported.
>>
>> Okay.
>>
>>> I also fixed #ifdef INCLUDE_NMT in whitebox.cpp that should instead be
>>> #if INCLUDE_NMT. The source within the #if is now properly excluded from
>>> minimal VM builds.
>>
>> Okay.
>>
>>> The addition of Platform.isArm() is to support changes in closed source.
>>
>> I hate seeing these kinds of methods. Add a new platform, add a new
>> method - yuck! :(
>>
>> We could just use getOsArch().toLowerCase().startsWith("arm") directly.
>>
>> I'd even prefer to see:
>>
>> boolean isArch(String arch) {
>>   return osArch.toLowerCase().startsWith(arch.toLowerCase());
>> }
>>
>> and similarly for the OS - but that is going beyond this fix :)
> I'm not particularly tied to any specific way of doing this. I can do
> either of the above if you wish. Just let me know your preference.

Drop isArm() please and change the closed usage to 
getOsArch().toLowerCase().startsWith("arm").

I'll file a RFE for Platform :)

Thanks,
David

> Chris
>>
>> Thanks,
>> David
>>
>>> Testing was done using the existing NMT tests, verifying that they now
>>> pass on platforms where NMT detail is not supported, and still pass on
>>> platforms where NMT detail is supported. A jprt job is currently in the
>>> queue to run all NMT jtreg tests on all platforms supported by jprt.
>>>
>>> Thanks!
>>>
>>> Chris Plummer
>

From christian.tornqvist at oracle.com  Tue Aug 20 20:50:13 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Tue, 20 Aug 2013 23:50:13 -0400
Subject: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on
	platforms	if NMT detail is not supported
In-Reply-To: <5214173C.7000806@oracle.com>
References: <5213C483.1060102@oracle.com> <5214173C.7000806@oracle.com>
Message-ID: <01f701ce9e21$8b3ec860$a1bc5920$@oracle.com>

>I hate seeing these kinds of methods. Add a new platform, add a new method
- yuck! :(

We're not adding platforms at a rate where this is really a problem

>boolean isArch(String arch) {
>   return osArch.toLowerCase().startsWith(arch.toLowerCase());
>}
>
>and similarly for the OS - but that is going beyond this fix :)

This is really a bad idea, the idea is to make it easy and less error prone
to do these checks, not the other way around. I strongly disagree with this
and think this change should _not_ be made.

/Christian

-----Original Message-----
From: hotspot-runtime-dev-bounces at openjdk.java.net
[mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David
Holmes
Sent: Tuesday, August 20, 2013 9:26 PM
To: Chris Plummer
Cc: hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on
platforms if NMT detail is not supported

Hi Chris,

On 21/08/2013 5:33 AM, Chris Plummer wrote:
> https://jbs.oracle.com/bugs/browse/JDK-8020829
> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-03/
>
> On some platforms, NMT detail is not supported, and this was causing 
> some jtreg tests to fail. These tests now query a new WhiteBox API to 
> see if NMT detail is supported, and now behave properly if it is not 
> supported.

Okay.

> I also fixed #ifdef INCLUDE_NMT in whitebox.cpp that should instead be 
> #if INCLUDE_NMT. The source within the #if is now properly excluded 
> from minimal VM builds.

Okay.

> The addition of Platform.isArm() is to support changes in closed source.

I hate seeing these kinds of methods. Add a new platform, add a new method -
yuck! :(

We could just use getOsArch().toLowerCase().startsWith("arm") directly.

I'd even prefer to see:

boolean isArch(String arch) {
   return osArch.toLowerCase().startsWith(arch.toLowerCase());
}

and similarly for the OS - but that is going beyond this fix :)

Thanks,
David

> Testing was done using the existing NMT tests, verifying that they now 
> pass on platforms where NMT detail is not supported, and still pass on 
> platforms where NMT detail is supported. A jprt job is currently in 
> the queue to run all NMT jtreg tests on all platforms supported by jprt.
>
> Thanks!
>
> Chris Plummer


From yumin.qi at oracle.com  Tue Aug 20 22:21:49 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 20 Aug 2013 22:21:49 -0700
Subject: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even
	when BUILD_WIN_SA != 1
In-Reply-To: <5213DB89.6080705@oracle.com>
References: <5213DB89.6080705@oracle.com>
Message-ID: <52144E6D.8080905@oracle.com>

Ioi,

   One question, SKIP_GENERATED, is this a environment variable or need 
to give on command?
   Others looks OK.

Thanks
Yumin


On 8/20/2013 2:11 PM, Ioi Lam wrote:
> |Please review a very small fix:||
> ||
> ||http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/||
> ||
> ||Bug: make/windows/build_vm_def.sh takes too long even when 
> BUILD_WIN_SA != 1||
> ||
> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023406||
> ||https://jbs.oracle.com/bugs/browse/JDK-8023406||
> ||
> ||Summary of fix:||
> ||
> ||    Reduce Windows build time to improve developer productivity.||
> ||
> ||    If BUILD_WIN_SA != 1, don't bother to generate vm.def, whose sole ||
> ||    purpose is for SA to determine the type information of C++ 
> objects.||
> ||
> ||    Instead, this rather eye-catching warning is printed, and 10 
> seconds||
> ||    are saved in the build cycle.||
> ||
> ||        ***||
> ||        *** Not building SA: BUILD_WIN_SA != 1||
> ||        *** C++ Vtables NOT included in vm.def||
> ||        *** This jvm.dll will NOT work properly with SA.||
> ||        ***||
> ||        *** When in doubt, set BUILD_WIN_SA=1, clean and rebuild.||
> ||        ***||
> ||
> ||    This does not affect JPRT -- JPRT always sets BUILD_WIN_SA=1.||
> ||
> ||Result: ||
> ||
> ||    Touch 1 .cpp file; rebuild: Total time is reduced 15 seconds -> 
> 5 seconds.||
> ||
> ||Tests:||
> ||
>     [0] Manual testing with both create.bat (IDE build) and build.bat
>         VS 2008 + VS2010
> ||    [1] JPRT (windows.* only)||
> ||    [2] I built a jvm.dll without BUILD_WIN_SA=0, and it ran 
> Eclipsed without||
> ||        any problem.||
> ||
> ||Thanks||
> ||- Ioi| 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130820/f1e63289/attachment.html 

From vladimir.x.ivanov at oracle.com  Tue Aug 20 22:55:16 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 21 Aug 2013 09:55:16 +0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <52140E57.8030409@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213BD48.3030701@oracle.com>
	<5213E5EA.8000504@oracle.com> <5213ECB8.7030503@oracle.com>
	<5213EF2A.2090203@oracle.com> <52140E57.8030409@oracle.com>
Message-ID: <52145644.3030200@oracle.com>

David,

To be accurate, ExceptionMark terminates the process both in debug & 
product VM when pending exception is present:

src/share/vm/utilities/exceptions.cpp:
ExceptionMark::~ExceptionMark() {
   if (_thread->has_pending_exception()) {
     Handle exception(_thread, _thread->pending_exception());
     _thread->clear_pending_exception(); // Needed to avoid infinite 
recursion
     if (is_init_completed()) {
       exception->print();
       fatal("ExceptionMark destructor expects no pending exceptions");
     } else {
       vm_exit_during_initialization(exception);
     }
   }
}

For stand-alone Java application such behavior is reasonable, but in the 
case VM is embedded into another application I don't think VM 
initialization failure is fatal per se.

Best regards,
Vladimir Ivanov

On 8/21/13 4:48 AM, David Holmes wrote:
> On 21/08/2013 8:35 AM, Coleen Phillimore wrote:
>>
>> On 08/20/2013 06:24 PM, Coleen Phillimore wrote:
>>>
>>>
>>> Vladimir,
>>>
>>> You are right, it's broken.  Calvin is working on a similar issue in
>>> bug https://jbs.oracle.com/bugs/browse/JDK-8020675.
>>
>> Reading more, I think Calvin's issue is similar but different.  I will
>> file a new bug for the Threads::create_vm() EXCEPTION_MARK.
>
> I think the intent is that we never, ever expect to get any exceptions
> during VM initialization unless we have a significant bug. The
> EXCEPTION_MARK detects that bug in debug builds.
>
> I have a vague recollection of the CHECK_0 "bug" being discussed when I
> was in runtime.
>
> David
>
>> Coleen
>>
>>>
>>> I think you should check in your code and we'll fix all the
>>> CHECK_0/EXCEPTION_MARK problems at once.
>>>
>>> Thanks for checking this out.
>>> Coleen
>>>
>>> On 08/20/2013 05:55 PM, Vladimir Ivanov wrote:
>>>> Coleen,
>>>>
>>>> Thank you for the review.
>>>> It doesn't cause a deadlock anymore because class loading is
>>>> guaranteed to be performed in singe-threaded mode.
>>>>
>>>> Regarding CHECK_0 -> CHECK_(JNI_ERR) change you propose, there's one
>>>> problem. All pending exceptions are fatal right now: even if it
>>>> returns JNI_OK, there's an ExceptionMark on the stack which crashes
>>>> VM if any pending exceptions are present.
>>>>
>>>> Considering that JNI_CreateJavaVM uses Thread::create_vm and failure
>>>> during VM initialization can crash the whole app, I don't think such
>>>> behavior is correct.
>>>>
>>>> So, I have 2 questions here:
>>>>     1) what behavior do we prefer?
>>>>     2) if we want to change current behavior, doesn't it deserve a
>>>> separate fix?
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 8/20/13 11:02 PM, Coleen Phillimore wrote:
>>>>>
>>>>> Vladimir,
>>>>>
>>>>> The code that you added is copied from the initialization code
>>>>> above.  I
>>>>> think they have a problem.  If initialization fails, there is a
>>>>> CHECK_0
>>>>> at the end of the call.  CHECK_0 returns JNI_OK to the caller, which
>>>>> goes ahead with the initialization.
>>>>>
>>>>> Can you change all of these to CHECK_(JNI_ERR) so that the caller can
>>>>> deal with the error?  It would be good to see if the caller does the
>>>>> right thing with a JNI_ERR.
>>>>>
>>>>> Otherwise, I think the code is fine if the initialization of these
>>>>> classes doesn't cause deadlocks in their new place.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 08/20/2013 01:05 PM, Vladimir Ivanov wrote:
>>>>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>>>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>>>>
>>>>>> Some classes in j.l.invoke have circular dependencies between them
>>>>>> which leads to deadlocks during class initialization when multiple
>>>>>> threads exercise JSR292 functionality.
>>>>>>
>>>>>> JSR292 core classes are among "well-known" classes to VM and they are
>>>>>> preloaded during VM startup (see
>>>>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>>>>> force preloaded classes to be initialized (doesn't execute static
>>>>>> initializers). Thus, these classes should be explicitly
>>>>>> pre-initialized in order to avoid deadlocks.
>>>>>>
>>>>>> Based on my observations of possible deadlock scenarios, I chose 3
>>>>>> classes to pre-initialize:
>>>>>>     - MethodHandle
>>>>>>     - MemberName
>>>>>>     - MethodHandleNatives
>>>>>>
>>>>>> I placed the code right after compilers initialization because during
>>>>>> method resolution for signature polymorphic intrinsics, compilation
>>>>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>>>>>> for details) and they are missed if compiler subsystem isn't ready
>>>>>> yet.
>>>>>>
>>>>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>>>>> vm.mlvm.testlist, octane.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>
>>>
>>

From vladimir.x.ivanov at oracle.com  Tue Aug 20 23:00:20 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 21 Aug 2013 10:00:20 +0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <52140F51.9050103@oracle.com>
References: <5213A1E9.1090002@oracle.com> <52140F51.9050103@oracle.com>
Message-ID: <52145774.8000303@oracle.com>

David,

Thank you for the review.

On 8/21/13 4:52 AM, David Holmes wrote:
> Hi Vladimir,
>
> The initialization code location looks good to me.
>
> I presume the shutdown hook in the test (another reason this needs to be
> othervm!) is to see a dump via ctrl-C if there is a hang?
Yes, exactly.

Best regards,
Vladimir Ivanov

>
> David
>
> On 21/08/2013 3:05 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>
>> Some classes in j.l.invoke have circular dependencies between them which
>> leads to deadlocks during class initialization when multiple threads
>> exercise JSR292 functionality.
>>
>> JSR292 core classes are among "well-known" classes to VM and they are
>> preloaded during VM startup (see
>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>> force preloaded classes to be initialized (doesn't execute static
>> initializers). Thus, these classes should be explicitly pre-initialized
>> in order to avoid deadlocks.
>>
>> Based on my observations of possible deadlock scenarios, I chose 3
>> classes to pre-initialize:
>>      - MethodHandle
>>      - MemberName
>>      - MethodHandleNatives
>>
>> I placed the code right after compilers initialization because during
>> method resolution for signature polymorphic intrinsics, compilation
>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic for
>> details) and they are missed if compiler subsystem isn't ready yet.
>>
>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>> vm.mlvm.testlist, octane.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov

From vladimir.x.ivanov at oracle.com  Tue Aug 20 23:16:08 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 21 Aug 2013 10:16:08 +0400
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <5213ECB8.7030503@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213BD48.3030701@oracle.com>
	<5213E5EA.8000504@oracle.com> <5213ECB8.7030503@oracle.com>
Message-ID: <52145B28.1060605@oracle.com>

Coleen, thank you.

Best regards,
Vladimir Ivanov

On 8/21/13 2:24 AM, Coleen Phillimore wrote:
>
>
> Vladimir,
>
> You are right, it's broken.  Calvin is working on a similar issue in bug
> https://jbs.oracle.com/bugs/browse/JDK-8020675.
>
> I think you should check in your code and we'll fix all the
> CHECK_0/EXCEPTION_MARK problems at once.
>
> Thanks for checking this out.
> Coleen
>
> On 08/20/2013 05:55 PM, Vladimir Ivanov wrote:
>> Coleen,
>>
>> Thank you for the review.
>> It doesn't cause a deadlock anymore because class loading is
>> guaranteed to be performed in singe-threaded mode.
>>
>> Regarding CHECK_0 -> CHECK_(JNI_ERR) change you propose, there's one
>> problem. All pending exceptions are fatal right now: even if it
>> returns JNI_OK, there's an ExceptionMark on the stack which crashes VM
>> if any pending exceptions are present.
>>
>> Considering that JNI_CreateJavaVM uses Thread::create_vm and failure
>> during VM initialization can crash the whole app, I don't think such
>> behavior is correct.
>>
>> So, I have 2 questions here:
>>     1) what behavior do we prefer?
>>     2) if we want to change current behavior, doesn't it deserve a
>> separate fix?
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 8/20/13 11:02 PM, Coleen Phillimore wrote:
>>>
>>> Vladimir,
>>>
>>> The code that you added is copied from the initialization code above.  I
>>> think they have a problem.  If initialization fails, there is a CHECK_0
>>> at the end of the call.  CHECK_0 returns JNI_OK to the caller, which
>>> goes ahead with the initialization.
>>>
>>> Can you change all of these to CHECK_(JNI_ERR) so that the caller can
>>> deal with the error?  It would be good to see if the caller does the
>>> right thing with a JNI_ERR.
>>>
>>> Otherwise, I think the code is fine if the initialization of these
>>> classes doesn't cause deadlocks in their new place.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 08/20/2013 01:05 PM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>>
>>>> Some classes in j.l.invoke have circular dependencies between them
>>>> which leads to deadlocks during class initialization when multiple
>>>> threads exercise JSR292 functionality.
>>>>
>>>> JSR292 core classes are among "well-known" classes to VM and they are
>>>> preloaded during VM startup (see
>>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>>> force preloaded classes to be initialized (doesn't execute static
>>>> initializers). Thus, these classes should be explicitly
>>>> pre-initialized in order to avoid deadlocks.
>>>>
>>>> Based on my observations of possible deadlock scenarios, I chose 3
>>>> classes to pre-initialize:
>>>>     - MethodHandle
>>>>     - MemberName
>>>>     - MethodHandleNatives
>>>>
>>>> I placed the code right after compilers initialization because during
>>>> method resolution for signature polymorphic intrinsics, compilation
>>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>>>> for details) and they are missed if compiler subsystem isn't ready yet.
>>>>
>>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>>> vm.mlvm.testlist, octane.
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>
>

From david.holmes at oracle.com  Wed Aug 21 00:46:24 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 17:46:24 +1000
Subject: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on platforms
	if NMT detail is not supported
In-Reply-To: <01f701ce9e21$8b3ec860$a1bc5920$@oracle.com>
References: <5213C483.1060102@oracle.com> <5214173C.7000806@oracle.com>
	<01f701ce9e21$8b3ec860$a1bc5920$@oracle.com>
Message-ID: <52147050.6080906@oracle.com>

On 21/08/2013 1:50 PM, Christian Tornqvist wrote:
>> I hate seeing these kinds of methods. Add a new platform, add a new method
> - yuck! :(
>
> We're not adding platforms at a rate where this is really a problem

The point is that every time we do add a platform - and there are a 
couple more in the pipeline now - we have to find all these places where 
the known platforms have been hardwired. It is in hotspot code, JDK code 
and test code. That isn't scalable or maintainable and at best should be 
done in one place.

>> boolean isArch(String arch) {
>>    return osArch.toLowerCase().startsWith(arch.toLowerCase());
>> }
>>
>> and similarly for the OS - but that is going beyond this fix :)
>
> This is really a bad idea, the idea is to make it easy and less error prone
> to do these checks, not the other way around. I strongly disagree with this
> and think this change should _not_ be made.

I agree the OS usage would be a problem simply because a lot of people 
would be unaware of the obscure historical strings used for the OS "name".

Anyway no change is happening - including not adding isArm().

Cheers,
David

>
> /Christian
>
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net
> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David
> Holmes
> Sent: Tuesday, August 20, 2013 9:26 PM
> To: Chris Plummer
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on
> platforms if NMT detail is not supported
>
> Hi Chris,
>
> On 21/08/2013 5:33 AM, Chris Plummer wrote:
>> https://jbs.oracle.com/bugs/browse/JDK-8020829
>> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-03/
>>
>> On some platforms, NMT detail is not supported, and this was causing
>> some jtreg tests to fail. These tests now query a new WhiteBox API to
>> see if NMT detail is supported, and now behave properly if it is not
>> supported.
>
> Okay.
>
>> I also fixed #ifdef INCLUDE_NMT in whitebox.cpp that should instead be
>> #if INCLUDE_NMT. The source within the #if is now properly excluded
>> from minimal VM builds.
>
> Okay.
>
>> The addition of Platform.isArm() is to support changes in closed source.
>
> I hate seeing these kinds of methods. Add a new platform, add a new method -
> yuck! :(
>
> We could just use getOsArch().toLowerCase().startsWith("arm") directly.
>
> I'd even prefer to see:
>
> boolean isArch(String arch) {
>     return osArch.toLowerCase().startsWith(arch.toLowerCase());
> }
>
> and similarly for the OS - but that is going beyond this fix :)
>
> Thanks,
> David
>
>> Testing was done using the existing NMT tests, verifying that they now
>> pass on platforms where NMT detail is not supported, and still pass on
>> platforms where NMT detail is supported. A jprt job is currently in
>> the queue to run all NMT jtreg tests on all platforms supported by jprt.
>>
>> Thanks!
>>
>> Chris Plummer
>

From david.holmes at oracle.com  Wed Aug 21 00:50:20 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 17:50:20 +1000
Subject: RFR (XS): 8022595: JSR292: deadlock during class loading of
	MethodHandles, MethodHandleImpl & MethodHandleNatives
In-Reply-To: <52145644.3030200@oracle.com>
References: <5213A1E9.1090002@oracle.com> <5213BD48.3030701@oracle.com>
	<5213E5EA.8000504@oracle.com> <5213ECB8.7030503@oracle.com>
	<5213EF2A.2090203@oracle.com> <52140E57.8030409@oracle.com>
	<52145644.3030200@oracle.com>
Message-ID: <5214713C.1050904@oracle.com>

On 21/08/2013 3:55 PM, Vladimir Ivanov wrote:
> David,
>
> To be accurate, ExceptionMark terminates the process both in debug &
> product VM when pending exception is present:

Okay.

> src/share/vm/utilities/exceptions.cpp:
> ExceptionMark::~ExceptionMark() {
>    if (_thread->has_pending_exception()) {
>      Handle exception(_thread, _thread->pending_exception());
>      _thread->clear_pending_exception(); // Needed to avoid infinite
> recursion
>      if (is_init_completed()) {
>        exception->print();
>        fatal("ExceptionMark destructor expects no pending exceptions");
>      } else {
>        vm_exit_during_initialization(exception);
>      }
>    }
> }
>
> For stand-alone Java application such behavior is reasonable, but in the
> case VM is embedded into another application I don't think VM
> initialization failure is fatal per se.

No it isn't, but we have a dozen different things that cause VM 
initialization to abort the process when it shouldn't. :( You would 
think this would have been handled from the beginning but ... <sigh>

I'm not saying don't fix this, just that it is one of many things that 
need fixing in this area. And there are other places where we have 
EXCEPTION_MARKS placed right before code that throws an exception. :(

Cheers,
David

> Best regards,
> Vladimir Ivanov
>
> On 8/21/13 4:48 AM, David Holmes wrote:
>> On 21/08/2013 8:35 AM, Coleen Phillimore wrote:
>>>
>>> On 08/20/2013 06:24 PM, Coleen Phillimore wrote:
>>>>
>>>>
>>>> Vladimir,
>>>>
>>>> You are right, it's broken.  Calvin is working on a similar issue in
>>>> bug https://jbs.oracle.com/bugs/browse/JDK-8020675.
>>>
>>> Reading more, I think Calvin's issue is similar but different.  I will
>>> file a new bug for the Threads::create_vm() EXCEPTION_MARK.
>>
>> I think the intent is that we never, ever expect to get any exceptions
>> during VM initialization unless we have a significant bug. The
>> EXCEPTION_MARK detects that bug in debug builds.
>>
>> I have a vague recollection of the CHECK_0 "bug" being discussed when I
>> was in runtime.
>>
>> David
>>
>>> Coleen
>>>
>>>>
>>>> I think you should check in your code and we'll fix all the
>>>> CHECK_0/EXCEPTION_MARK problems at once.
>>>>
>>>> Thanks for checking this out.
>>>> Coleen
>>>>
>>>> On 08/20/2013 05:55 PM, Vladimir Ivanov wrote:
>>>>> Coleen,
>>>>>
>>>>> Thank you for the review.
>>>>> It doesn't cause a deadlock anymore because class loading is
>>>>> guaranteed to be performed in singe-threaded mode.
>>>>>
>>>>> Regarding CHECK_0 -> CHECK_(JNI_ERR) change you propose, there's one
>>>>> problem. All pending exceptions are fatal right now: even if it
>>>>> returns JNI_OK, there's an ExceptionMark on the stack which crashes
>>>>> VM if any pending exceptions are present.
>>>>>
>>>>> Considering that JNI_CreateJavaVM uses Thread::create_vm and failure
>>>>> during VM initialization can crash the whole app, I don't think such
>>>>> behavior is correct.
>>>>>
>>>>> So, I have 2 questions here:
>>>>>     1) what behavior do we prefer?
>>>>>     2) if we want to change current behavior, doesn't it deserve a
>>>>> separate fix?
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>> On 8/20/13 11:02 PM, Coleen Phillimore wrote:
>>>>>>
>>>>>> Vladimir,
>>>>>>
>>>>>> The code that you added is copied from the initialization code
>>>>>> above.  I
>>>>>> think they have a problem.  If initialization fails, there is a
>>>>>> CHECK_0
>>>>>> at the end of the call.  CHECK_0 returns JNI_OK to the caller, which
>>>>>> goes ahead with the initialization.
>>>>>>
>>>>>> Can you change all of these to CHECK_(JNI_ERR) so that the caller can
>>>>>> deal with the error?  It would be good to see if the caller does the
>>>>>> right thing with a JNI_ERR.
>>>>>>
>>>>>> Otherwise, I think the code is fine if the initialization of these
>>>>>> classes doesn't cause deadlocks in their new place.
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>> On 08/20/2013 01:05 PM, Vladimir Ivanov wrote:
>>>>>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>>>>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>>>>>
>>>>>>> Some classes in j.l.invoke have circular dependencies between them
>>>>>>> which leads to deadlocks during class initialization when multiple
>>>>>>> threads exercise JSR292 functionality.
>>>>>>>
>>>>>>> JSR292 core classes are among "well-known" classes to VM and they
>>>>>>> are
>>>>>>> preloaded during VM startup (see
>>>>>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>>>>>> force preloaded classes to be initialized (doesn't execute static
>>>>>>> initializers). Thus, these classes should be explicitly
>>>>>>> pre-initialized in order to avoid deadlocks.
>>>>>>>
>>>>>>> Based on my observations of possible deadlock scenarios, I chose 3
>>>>>>> classes to pre-initialize:
>>>>>>>     - MethodHandle
>>>>>>>     - MemberName
>>>>>>>     - MethodHandleNatives
>>>>>>>
>>>>>>> I placed the code right after compilers initialization because
>>>>>>> during
>>>>>>> method resolution for signature polymorphic intrinsics, compilation
>>>>>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>>>>>>> for details) and they are missed if compiler subsystem isn't ready
>>>>>>> yet.
>>>>>>>
>>>>>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>>>>>> vm.mlvm.testlist, octane.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>
>>>>
>>>

From roland.westrelin at oracle.com  Wed Aug 21 01:01:55 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 21 Aug 2013 10:01:55 +0200
Subject: RFR(S): 8016277: Crash in nmethod::is_compiled_by_c1() on x86
Message-ID: <7658B9CF-B363-452D-A0AD-B93F4D574D07@oracle.com>

http://cr.openjdk.java.net/~roland/8016277/webrev.00/

Once an nmethod becomes zombie, its Method can be reclaimed so the reference to the Method in the nmethod becomes invalid.

My change sets the nmethod's _method to NULL once the nmethod is in the zombie state so that we risk using an invalid reference. The crash itself was cause by nmethod::is_native_method() (which uses the Method pointer of the nmethod) called from nmethod::is_compiled_by_c1() by some verification code. I changed the implementation of the nmethod::is_compiled_by_* so that they don't need to call is_native_method() (a call that was anyway useless because for a native method the compiler() is NULL).

Roland.

From staffan.larsen at oracle.com  Wed Aug 21 01:44:38 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 21 Aug 2013 10:44:38 +0200
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
Message-ID: <E6ADB70E-5966-4548-865D-D80CB9871E40@oracle.com>

I still need a Reviewer to ok this.

Thanks,
/Staffan

On 19 aug 2013, at 11:08, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> We are using the mach thread port name as the os thread identifier on OS X. We get this value by calling mach_thread_self(), but we (I) didn't realize that this "port" resource is reference counted and mach_thread_self() increases the reference count, but we never call mach_port_deallocate() to decrease the reference count. This leads to a resource leak and eventually mach_thread_self() will return 0 to indicate that we are out of ports. Running out of ports causes the pthreads implementation (which is built on top of mach) to spin forever in some calls (most notably in this case pthread_kill()).
> 
> One way to fix this is to make sure we call mach_port_deallocate() for each call to mach_thread_self(). However, this adds extra complexity to the code and also makes it slower. Another solution is to ask pthreads for the mach port name that it already has. Pthreads provides the function pthread_mach_thread_np() for this purpose. In this case there is no need to deallocate the port since pthread_mach_thread_np() will not increase the reference count (and pthreads will call deallocate on the port once the thread terminates).
> 
> This fix has been verified by seeing that the number of ports the process has allocated does not increase in Activity Monitor (or top). It has also passed JPRT testing on all platforms.
> 
> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
> (there is not publicly visible bug for this)
> 
> Thanks,
> /Staffan


From staffan.larsen at oracle.com  Wed Aug 21 02:20:35 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 21 Aug 2013 11:20:35 +0200
Subject: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even
	when BUILD_WIN_SA != 1
In-Reply-To: <5213DB89.6080705@oracle.com>
References: <5213DB89.6080705@oracle.com>
Message-ID: <F6C65BB8-2553-4336-B9B2-A0C71097DF0E@oracle.com>

Looks good.

/Staffan

On 20 aug 2013, at 23:11, Ioi Lam <ioi.lam at oracle.com> wrote:

> Please review a very small fix:
> 
>     http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/
> 
> Bug: make/windows/build_vm_def.sh takes too long even when BUILD_WIN_SA != 1
> 
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023406
>     https://jbs.oracle.com/bugs/browse/JDK-8023406
> 
> Summary of fix:
> 
>     Reduce Windows build time to improve developer productivity.
> 
>     If BUILD_WIN_SA != 1, don't bother to generate vm.def, whose sole 
>     purpose is for SA to determine the type information of C++ objects.
> 
>     Instead, this rather eye-catching warning is printed, and 10 seconds
>     are saved in the build cycle.
> 
>         ***
>         *** Not building SA: BUILD_WIN_SA != 1
>         *** C++ Vtables NOT included in vm.def
>         *** This jvm.dll will NOT work properly with SA.
>         ***
>         *** When in doubt, set BUILD_WIN_SA=1, clean and rebuild.
>         ***
> 
>     This does not affect JPRT -- JPRT always sets BUILD_WIN_SA=1.
> 
> Result:    
> 
>     Touch 1 .cpp file; rebuild: Total time is reduced 15 seconds -> 5 seconds.
> 
> Tests:
> 
>     [0] Manual testing with both create.bat (IDE build) and build.bat
>         VS 2008 + VS2010
>     [1] JPRT (windows.* only)
>     [2] I built a jvm.dll without BUILD_WIN_SA=0, and it ran Eclipsed without
>         any problem.
> 
> Thanks
> - Ioi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130821/e7cfb2b6/attachment.html 

From david.holmes at oracle.com  Wed Aug 21 03:08:49 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 20:08:49 +1000
Subject: RFR: 8022808: Kitchensink hangs on macos
In-Reply-To: <E6ADB70E-5966-4548-865D-D80CB9871E40@oracle.com>
References: <C6D806DD-F760-4911-82CF-985621A84A46@oracle.com>
	<E6ADB70E-5966-4548-865D-D80CB9871E40@oracle.com>
Message-ID: <521491B1.7010208@oracle.com>

Reviewed!

Thanks,
David

On 21/08/2013 6:44 PM, Staffan Larsen wrote:
> I still need a Reviewer to ok this.
>
> Thanks,
> /Staffan
>
> On 19 aug 2013, at 11:08, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>
>> We are using the mach thread port name as the os thread identifier on OS X. We get this value by calling mach_thread_self(), but we (I) didn't realize that this "port" resource is reference counted and mach_thread_self() increases the reference count, but we never call mach_port_deallocate() to decrease the reference count. This leads to a resource leak and eventually mach_thread_self() will return 0 to indicate that we are out of ports. Running out of ports causes the pthreads implementation (which is built on top of mach) to spin forever in some calls (most notably in this case pthread_kill()).
>>
>> One way to fix this is to make sure we call mach_port_deallocate() for each call to mach_thread_self(). However, this adds extra complexity to the code and also makes it slower. Another solution is to ask pthreads for the mach port name that it already has. Pthreads provides the function pthread_mach_thread_np() for this purpose. In this case there is no need to deallocate the port since pthread_mach_thread_np() will not increase the reference count (and pthreads will call deallocate on the port once the thread terminates).
>>
>> This fix has been verified by seeing that the number of ports the process has allocated does not increase in Activity Monitor (or top). It has also passed JPRT testing on all platforms.
>>
>> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
>> (there is not publicly visible bug for this)
>>
>> Thanks,
>> /Staffan
>

From david.simms at oracle.com  Wed Aug 21 03:30:29 2013
From: david.simms at oracle.com (David Simms)
Date: Wed, 21 Aug 2013 12:30:29 +0200
Subject: RFR (S): 8022683 : JNI GetStringUTFChars should return NULL on
	allocation failure not abort the VM
In-Reply-To: <52119635.1050908@oracle.com>
References: <520E3B16.2040100@oracle.com> <52119635.1050908@oracle.com>
Message-ID: <521496C5.6020805@oracle.com>


Been a little side-track, reply inline...

On 19/08/13 05:51, David Holmes wrote:
> Hi David,
>
> On 17/08/2013 12:45 AM, David Simms wrote:
>> Hello all,
>>
>> Need reviewers on a JDK8 fix for:
>> http://bugs.sun.com/view_bug.do?bug_id=8022683
>>
>> Found the following functions need to return NULL as suggested by the
>> JNI spec
>> (http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html): 
>>
>>
>>   * GetStringChars()
>>   * GetStringUTFChars()
>>   * Get<PrimitiveType>ArrayElements() family of array getters (same
>>     generating macro).
>>
>> Although the specification suggests OOME may be thrown by certain
>> functions, the documentation on the aforementioned functions does not
>> suggest "throws". So they return NULL now without aborting the JVM as
>> before.
>
> There is always come contention with the JNI spec as to whether the 
> intent is as defined by the original JNI spec book, or whether it is 
> reflected in what is considered the "official spec". :)
>
Agreed, but let's just take the documentation developers have to go on.
>> It was assumed the meaning of "isCopy" is undefined given a NULL result,
>> in keeping with the rest of jni.cpp.
>
> Even so I think it preferable to not set it unless the operation 
> succeeds.
>
Done
>> Also discovered allocation.hpp macros missing proper argument bracketing
>> (e.g. size passed in NEW_C_HEAP_ARRAY_RETURN_NULL()), fixed them up
>> since I was there (and they caused trouble).
>
> I can only see size causing a problem because it is used in an 
> expression. The rest seems somewhat overkill.
>
Fine, no need to get too happy, also done.

    Been used to as a matter of practice bracketing anything involving
    possible expression/calculation, i.e. pointer math.

Updated webrev:
>> Webrev:
>>
>> http://cr.openjdk.java.net/~dsimms/8022683/
>> <http://cr.openjdk.java.net/%7Edsimms/8022683/>
>
> One concern I have is in how the dtrace probes will handle things if 
> buf/result is NULL?
Previous behavior was to exit the vm with OOM error (i.e.: 
vm_exit_out_of_memory()), which dtrace doesn't handle (so we are good).

Begs the question, how many applications will now simply crash within 
their native code, and does this change reduce the amount of diagnostics 
information. Whilst I prefer to stick the API documentation, wondering 
if this will be practical...  Okay tested with -Xcheck:jni which catches 
the problem (so we are good).

>
> Thanks,
> David
>
>> Testing:
>>
>> Attached "unit test" to bug, naive test program to trigger OOM. It is
>> not suitable for automated testing. Ideally require hooks into the JVM
>> to simulate OOM during JNI calls.
>>
>> Cheers
>> /David Simms

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130821/0a1d5337/attachment.html 

From vladimir.kempik at oracle.com  Wed Aug 21 03:40:27 2013
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Wed, 21 Aug 2013 14:40:27 +0400
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <5213E517.5000106@oracle.com>
References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com>
	<8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com>
	<5213E517.5000106@oracle.com>
Message-ID: <5214991B.40107@oracle.com>

Thanks everyone for comments.

Here is updated webrev 
http://cr.openjdk.java.net/~vkempik/8020530/webrev.01/

Vladimir.
On 21.08.2013 1:52, Mandy Chung wrote:
>
> On 8/20/2013 5:38 AM, Staffan Larsen wrote:
>> That doesn't make a lot of sense to me. Why would a pool have 
>> undefined values?
>> The Metaspace pool has no max value (unless you specify 
>> -XX:MaxMetaspaceSize=), thus undefined.
>>
>>> If a subset of pools have undefined values why report completely 
>>> fallacious values of -1?
>> The javadoc for MemoryUsage says getMax() returns -1 if the maximum 
>> memory size is undefined.
>
> Yes the spec allows implementation of memory pools with undefined 
> max.  "used" and "committed" must have a value and the "committed" 
> memory is guaranteed to be available for the VM to use.  "max" will 
> give an idea of the upper bound how much memory can be allocated from 
> it; however, there is no guarantee that amount of memory is available 
> for the VM.
>
>>> It also isn't clear how this relates to the "committed" value in the 
>>> failure. What gets reported now?
>> I guess there can still be a committed value even if we don't have a 
>> max value for how much we might commit in the future: used <= 
>> committed <= max.
>
> The MemoryUsage constructor throws IAE if committed > max if max is 
> defined.  Perhaps it would be better if max should be Long.MAX_VALUE 
> if undefined (a different issue than this bug).
>
> Mandy
>
>> /Staffan
>>
>>> Thanks,
>>> David
>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>


From david.holmes at oracle.com  Wed Aug 21 03:47:50 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 20:47:50 +1000
Subject: RFR (S): 8022683 : JNI GetStringUTFChars should return NULL on
	allocation failure not abort the VM
In-Reply-To: <521496C5.6020805@oracle.com>
References: <520E3B16.2040100@oracle.com> <52119635.1050908@oracle.com>
	<521496C5.6020805@oracle.com>
Message-ID: <52149AD6.7050606@oracle.com>

On 21/08/2013 8:30 PM, David Simms wrote:
>
> Been a little side-track, reply inline...
>
> On 19/08/13 05:51, David Holmes wrote:
>> Hi David,
>>
>> On 17/08/2013 12:45 AM, David Simms wrote:
>>> Hello all,
>>>
>>> Need reviewers on a JDK8 fix for:
>>> http://bugs.sun.com/view_bug.do?bug_id=8022683
>>>
>>> Found the following functions need to return NULL as suggested by the
>>> JNI spec
>>> (http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html):
>>>
>>>
>>>   * GetStringChars()
>>>   * GetStringUTFChars()
>>>   * Get<PrimitiveType>ArrayElements() family of array getters (same
>>>     generating macro).
>>>
>>> Although the specification suggests OOME may be thrown by certain
>>> functions, the documentation on the aforementioned functions does not
>>> suggest "throws". So they return NULL now without aborting the JVM as
>>> before.
>>
>> There is always come contention with the JNI spec as to whether the
>> intent is as defined by the original JNI spec book, or whether it is
>> reflected in what is considered the "official spec". :)
>>
> Agreed, but let's just take the documentation developers have to go on.
>>> It was assumed the meaning of "isCopy" is undefined given a NULL result,
>>> in keeping with the rest of jni.cpp.
>>
>> Even so I think it preferable to not set it unless the operation
>> succeeds.
>>
> Done
>>> Also discovered allocation.hpp macros missing proper argument bracketing
>>> (e.g. size passed in NEW_C_HEAP_ARRAY_RETURN_NULL()), fixed them up
>>> since I was there (and they caused trouble).
>>
>> I can only see size causing a problem because it is used in an
>> expression. The rest seems somewhat overkill.
>>
> Fine, no need to get too happy, also done.
>
>     Been used to as a matter of practice bracketing anything involving
>     possible expression/calculation, i.e. pointer math.
>
> Updated webrev:
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~dsimms/8022683/
>>> <http://cr.openjdk.java.net/%7Edsimms/8022683/>
>>
>> One concern I have is in how the dtrace probes will handle things if
>> buf/result is NULL?
> Previous behavior was to exit the vm with OOM error (i.e.:
> vm_exit_out_of_memory()), which dtrace doesn't handle (so we are good).

My concern is, if the dtrace probes see a NULL will that cause them to 
crash or will they handle the NULL okay?

> Begs the question, how many applications will now simply crash within
> their native code, and does this change reduce the amount of diagnostics
> information. Whilst I prefer to stick the API documentation, wondering
> if this will be practical...  Okay tested with -Xcheck:jni which catches
> the problem (so we are good).

What did Xcheck:jni catch? Subsequent attempted use of the NULL in a JNI 
call? I would hope so. But if the application code doesn't check for 
NULL then it could still crash before the next JNI call.

This is always a risk with making behaviour compliant with spec. I think 
the risk is low because if we have exhausted C heap then the VM is about 
to die at any moment anyway. But we could add a release note to document 
this.

Thanks,
David

>>
>> Thanks,
>> David
>>
>>> Testing:
>>>
>>> Attached "unit test" to bug, naive test program to trigger OOM. It is
>>> not suitable for automated testing. Ideally require hooks into the JVM
>>> to simulate OOM during JNI calls.
>>>
>>> Cheers
>>> /David Simms
>

From markus.gronlund at oracle.com  Wed Aug 21 04:11:30 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 21 Aug 2013 04:11:30 -0700 (PDT)
Subject: RFR(XXS): Event based tracing framework needs a mutex for thread
	groups
Message-ID: <fb8c00ba-710e-4f81-a20f-03c6e506cd92@default>

Greetings,

?

Kindly asking for reviews for the following:

?

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

?

Webrev: http://cr.openjdk.java.net/~mgronlun/8023457/webrev01/

?

Thanks

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130821/cccb942c/attachment.html 

From staffan.larsen at oracle.com  Wed Aug 21 04:32:28 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 21 Aug 2013 13:32:28 +0200
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <5214991B.40107@oracle.com>
References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com>
	<8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com>
	<5213E517.5000106@oracle.com> <5214991B.40107@oracle.com>
Message-ID: <89095DA6-FE7B-45D9-873A-B323BD561060@oracle.com>

Still good.

Thanks,
/Staffan

On 21 aug 2013, at 12:40, Vladimir Kempik <vladimir.kempik at oracle.com> wrote:

> Thanks everyone for comments.
> 
> Here is updated webrev http://cr.openjdk.java.net/~vkempik/8020530/webrev.01/
> 
> Vladimir.
> On 21.08.2013 1:52, Mandy Chung wrote:
>> 
>> On 8/20/2013 5:38 AM, Staffan Larsen wrote:
>>> That doesn't make a lot of sense to me. Why would a pool have undefined values?
>>> The Metaspace pool has no max value (unless you specify -XX:MaxMetaspaceSize=), thus undefined.
>>> 
>>>> If a subset of pools have undefined values why report completely fallacious values of -1?
>>> The javadoc for MemoryUsage says getMax() returns -1 if the maximum memory size is undefined.
>> 
>> Yes the spec allows implementation of memory pools with undefined max.  "used" and "committed" must have a value and the "committed" memory is guaranteed to be available for the VM to use.  "max" will give an idea of the upper bound how much memory can be allocated from it; however, there is no guarantee that amount of memory is available for the VM.
>> 
>>>> It also isn't clear how this relates to the "committed" value in the failure. What gets reported now?
>>> I guess there can still be a committed value even if we don't have a max value for how much we might commit in the future: used <= committed <= max.
>> 
>> The MemoryUsage constructor throws IAE if committed > max if max is defined.  Perhaps it would be better if max should be Long.MAX_VALUE if undefined (a different issue than this bug).
>> 
>> Mandy
>> 
>>> /Staffan
>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>>> Thanks,
>>>>> Vladimir
>>>>> 
>> 
> 


From dmitry.samersoff at oracle.com  Wed Aug 21 04:37:45 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 21 Aug 2013 15:37:45 +0400
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <5214991B.40107@oracle.com>
References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com>
	<8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com>
	<5213E517.5000106@oracle.com> <5214991B.40107@oracle.com>
Message-ID: <5214A689.7050908@oracle.com>

Looks good for me.


On 2013-08-21 14:40, Vladimir Kempik wrote:
> Thanks everyone for comments.
> 
> Here is updated webrev
> http://cr.openjdk.java.net/~vkempik/8020530/webrev.01/
> 
> Vladimir.
> On 21.08.2013 1:52, Mandy Chung wrote:
>>
>> On 8/20/2013 5:38 AM, Staffan Larsen wrote:
>>> That doesn't make a lot of sense to me. Why would a pool have
>>> undefined values?
>>> The Metaspace pool has no max value (unless you specify
>>> -XX:MaxMetaspaceSize=), thus undefined.
>>>
>>>> If a subset of pools have undefined values why report completely
>>>> fallacious values of -1?
>>> The javadoc for MemoryUsage says getMax() returns -1 if the maximum
>>> memory size is undefined.
>>
>> Yes the spec allows implementation of memory pools with undefined
>> max.  "used" and "committed" must have a value and the "committed"
>> memory is guaranteed to be available for the VM to use.  "max" will
>> give an idea of the upper bound how much memory can be allocated from
>> it; however, there is no guarantee that amount of memory is available
>> for the VM.
>>
>>>> It also isn't clear how this relates to the "committed" value in the
>>>> failure. What gets reported now?
>>> I guess there can still be a committed value even if we don't have a
>>> max value for how much we might commit in the future: used <=
>>> committed <= max.
>>
>> The MemoryUsage constructor throws IAE if committed > max if max is
>> defined.  Perhaps it would be better if max should be Long.MAX_VALUE
>> if undefined (a different issue than this bug).
>>
>> Mandy
>>
>>> /Staffan
>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>
> 


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

From niclas.adlertz at oracle.com  Wed Aug 21 01:45:06 2013
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Wed, 21 Aug 2013 10:45:06 +0200
Subject: RFR(S): 8016277: Crash in nmethod::is_compiled_by_c1() on x86
In-Reply-To: <7658B9CF-B363-452D-A0AD-B93F4D574D07@oracle.com>
References: <7658B9CF-B363-452D-A0AD-B93F4D574D07@oracle.com>
Message-ID: <F569F6B5-8CBE-44CE-8C8A-C74DF53032DB@oracle.com>

Looks good! 

I would appreciate if you could add brackets to the simple if statements:
if (compiler() == NULL) {
  return false;
}

And also, if you could put the comment above the line instead of to the right:

// the Method may be reclaimed by class unloading now that the nmethod is in zombie state
_method = NULL;

Kind Regards,
Niclas Adlertz


On 21 aug 2013, at 10:01, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> http://cr.openjdk.java.net/~roland/8016277/webrev.00/
> 
> Once an nmethod becomes zombie, its Method can be reclaimed so the reference to the Method in the nmethod becomes invalid.
> 
> My change sets the nmethod's _method to NULL once the nmethod is in the zombie state so that we risk using an invalid reference. The crash itself was cause by nmethod::is_native_method() (which uses the Method pointer of the nmethod) called from nmethod::is_compiled_by_c1() by some verification code. I changed the implementation of the nmethod::is_compiled_by_* so that they don't need to call is_native_method() (a call that was anyway useless because for a native method the compiler() is NULL).
> 
> Roland.


From staffan.larsen at oracle.com  Wed Aug 21 06:53:24 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Wed, 21 Aug 2013 13:53:24 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022808: Kitchensink hangs on macos
Message-ID: <20130821135328.68EDC48A43@hg.openjdk.java.net>

Changeset: c6ec0a97b30a
Author:    sla
Date:      2013-08-21 13:18 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c6ec0a97b30a

8022808: Kitchensink hangs on macos
Summary: Use pthread_mach_thread_np() instead of mach_thread_self() to avoid leaking resources
Reviewed-by: dholmes, rbackman

! src/os/bsd/vm/os_bsd.cpp


From harold.seigel at oracle.com  Wed Aug 21 06:56:01 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 21 Aug 2013 09:56:01 -0400
Subject: Request for Review 8023393 Need to suppress info message if
	-Xcheck:jni used with libjsig.dylab on Mac OSX
In-Reply-To: <521414B3.6040903@oracle.com>
References: <5213C125.8020703@oracle.com> <521414B3.6040903@oracle.com>
Message-ID: <5214C6F1.2090403@oracle.com>

Thanks for the review.

Harold
On 8/20/2013 9:15 PM, David Holmes wrote:
> Looks good!
>
> Thanks,
> David
>
> On 21/08/2013 5:19 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this small change to fix bug 8023393.  The fix was copied
>> from the fix to os_linux.cpp for bug 7051189 and verified using the test
>> included in the webrev.  The test was also run successfully on Solaris
>> Sparc and X86 and Linux 64 and 32 bit platforms.  Additional testing was
>> done using JPRT.
>>
>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8023393/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8023393/>
>>
>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8023393
>>
>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8023393
>>
>> Thank you!
>> Harold


From coleen.phillimore at oracle.com  Wed Aug 21 07:34:46 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 21 Aug 2013 10:34:46 -0400
Subject: RFR(S): 8016277: Crash in nmethod::is_compiled_by_c1() on x86
In-Reply-To: <7658B9CF-B363-452D-A0AD-B93F4D574D07@oracle.com>
References: <7658B9CF-B363-452D-A0AD-B93F4D574D07@oracle.com>
Message-ID: <5214D006.1010703@oracle.com>


This looks good.   Thank you for narrowing this problem down.
Coleen

On 8/21/2013 4:01 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8016277/webrev.00/
>
> Once an nmethod becomes zombie, its Method can be reclaimed so the reference to the Method in the nmethod becomes invalid.
>
> My change sets the nmethod's _method to NULL once the nmethod is in the zombie state so that we risk using an invalid reference. The crash itself was cause by nmethod::is_native_method() (which uses the Method pointer of the nmethod) called from nmethod::is_compiled_by_c1() by some verification code. I changed the implementation of the nmethod::is_compiled_by_* so that they don't need to call is_native_method() (a call that was anyway useless because for a native method the compiler() is NULL).
>
> Roland.


From coleen.phillimore at oracle.com  Wed Aug 21 07:37:32 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 21 Aug 2013 10:37:32 -0400
Subject: Request for review: 8020530 Non heap memory size calculated
	incorrectly
In-Reply-To: <5214991B.40107@oracle.com>
References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com>
	<8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com>
	<5213E517.5000106@oracle.com> <5214991B.40107@oracle.com>
Message-ID: <5214D0AC.1000008@oracle.com>


Looks good, thanks!
Coleen

On 8/21/2013 6:40 AM, Vladimir Kempik wrote:
> Thanks everyone for comments.
>
> Here is updated webrev 
> http://cr.openjdk.java.net/~vkempik/8020530/webrev.01/
>
> Vladimir.
> On 21.08.2013 1:52, Mandy Chung wrote:
>>
>> On 8/20/2013 5:38 AM, Staffan Larsen wrote:
>>> That doesn't make a lot of sense to me. Why would a pool have 
>>> undefined values?
>>> The Metaspace pool has no max value (unless you specify 
>>> -XX:MaxMetaspaceSize=), thus undefined.
>>>
>>>> If a subset of pools have undefined values why report completely 
>>>> fallacious values of -1?
>>> The javadoc for MemoryUsage says getMax() returns -1 if the maximum 
>>> memory size is undefined.
>>
>> Yes the spec allows implementation of memory pools with undefined 
>> max.  "used" and "committed" must have a value and the "committed" 
>> memory is guaranteed to be available for the VM to use.  "max" will 
>> give an idea of the upper bound how much memory can be allocated from 
>> it; however, there is no guarantee that amount of memory is available 
>> for the VM.
>>
>>>> It also isn't clear how this relates to the "committed" value in 
>>>> the failure. What gets reported now?
>>> I guess there can still be a committed value even if we don't have a 
>>> max value for how much we might commit in the future: used <= 
>>> committed <= max.
>>
>> The MemoryUsage constructor throws IAE if committed > max if max is 
>> defined.  Perhaps it would be better if max should be Long.MAX_VALUE 
>> if undefined (a different issue than this bug).
>>
>> Mandy
>>
>>> /Staffan
>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>
>


From karen.kinnear at oracle.com  Wed Aug 21 08:14:50 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 21 Aug 2013 11:14:50 -0400
Subject: RFR(XXS): Event based tracing framework needs a mutex for thread
	groups
In-Reply-To: <fb8c00ba-710e-4f81-a20f-03c6e506cd92@default>
References: <fb8c00ba-710e-4f81-a20f-03c6e506cd92@default>
Message-ID: <51260B4E-9542-4BA3-B472-44AB428EA6C6@oracle.com>

Looks good.

thanks,
Karen

On Aug 21, 2013, at 7:11 AM, Markus Gr?nlund wrote:

> Greetings,
>  
> Kindly asking for reviews for the following:
>  
> Bugid: http://bugs.sun.com/view_bug.do?bug_id=8023457
>  
> Webrev: http://cr.openjdk.java.net/~mgronlun/8023457/webrev01/
>  
> Thanks
> Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130821/63a715da/attachment.html 

From markus.gronlund at oracle.com  Wed Aug 21 09:18:55 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 21 Aug 2013 09:18:55 -0700 (PDT)
Subject: RFR(XXS): Event based tracing framework needs a mutex for thread
	groups
In-Reply-To: <51260B4E-9542-4BA3-B472-44AB428EA6C6@oracle.com>
References: <fb8c00ba-710e-4f81-a20f-03c6e506cd92@default>
	<51260B4E-9542-4BA3-B472-44AB428EA6C6@oracle.com>
Message-ID: <8fe03bb7-b825-4bf9-835b-d1383c24e329@default>

Thanks Karen,

?

Based on some feedback, I have updated the naming of this lock and grouped them all inside the INCLUDE_TRACE guard.

?

Updated webrev:

http://cr.openjdk.java.net/~mgronlun/8023457/webrev02/

?

Thanks

Markus

?

From: Karen Kinnear 
Sent: den 21 augusti 2013 17:15
To: Markus Gr?nlund
Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(XXS): Event based tracing framework needs a mutex for thread groups

?

Looks good.

?

thanks,

Karen

?

On Aug 21, 2013, at 7:11 AM, Markus Gr?nlund wrote:





Greetings,

?

Kindly asking for reviews for the following:

?

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

?

Webrev:?http://cr.openjdk.java.net/~mgronlun/8023457/webrev01/

?

Thanks

Markus

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130821/351659b3/attachment.html 

From ioi.lam at oracle.com  Wed Aug 21 09:57:23 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 21 Aug 2013 09:57:23 -0700
Subject: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even
	when BUILD_WIN_SA != 1
In-Reply-To: <52144E6D.8080905@oracle.com>
References: <5213DB89.6080705@oracle.com> <52144E6D.8080905@oracle.com>
Message-ID: <5214F173.8000208@oracle.com>

Good catch! I tried to sneak this in :-)

SKIP_GENERATED can be set as an environment variable to skip the 
'generated' directory. I have an external script that checks if the file 
generated/_build_pch_file.cpp already exists. If so, it will set 
SKIP_GENERATED=1 before calling build.bat. This would save about 20 
seconds in build time.

I will revert the SKIP_GENERATED change for now and won't commit it, 
since the may affect the build if someone just happens to have 
SKIP_GENERATED=1 in their environment variables.

Thanks

- Ioi

On 08/20/2013 10:21 PM, Yumin Qi wrote:
> Ioi,
>
>   One question, SKIP_GENERATED, is this a environment variable or need 
> to give on command?
>   Others looks OK.
>
> Thanks
> Yumin
>
> On 8/20/2013 2:11 PM, Ioi Lam wrote:
>> |Please review a very small fix:||
>> ||
>> ||http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/||
>> ||
>> ||Bug: make/windows/build_vm_def.sh takes too long even when 
>> BUILD_WIN_SA != 1||
>> ||
>> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023406||
>> ||https://jbs.oracle.com/bugs/browse/JDK-8023406||
>> ||
>> ||Summary of fix:||
>> ||
>> ||    Reduce Windows build time to improve developer productivity.||
>> ||
>> ||    If BUILD_WIN_SA != 1, don't bother to generate vm.def, whose 
>> sole ||
>> ||    purpose is for SA to determine the type information of C++ 
>> objects.||
>> ||
>> ||    Instead, this rather eye-catching warning is printed, and 10 
>> seconds||
>> ||    are saved in the build cycle.||
>> ||
>> ||        ***||
>> ||        *** Not building SA: BUILD_WIN_SA != 1||
>> ||        *** C++ Vtables NOT included in vm.def||
>> ||        *** This jvm.dll will NOT work properly with SA.||
>> ||        ***||
>> ||        *** When in doubt, set BUILD_WIN_SA=1, clean and rebuild.||
>> ||        ***||
>> ||
>> ||    This does not affect JPRT -- JPRT always sets BUILD_WIN_SA=1.||
>> ||
>> ||Result: ||
>> ||
>> ||    Touch 1 .cpp file; rebuild: Total time is reduced 15 seconds -> 
>> 5 seconds.||
>> ||
>> ||Tests:||
>> ||
>>     [0] Manual testing with both create.bat (IDE build) and build.bat
>>         VS 2008 + VS2010
>> ||    [1] JPRT (windows.* only)||
>> ||    [2] I built a jvm.dll without BUILD_WIN_SA=0, and it ran 
>> Eclipsed without||
>> ||        any problem.||
>> ||
>> ||Thanks||
>> ||- Ioi| 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130821/ac43154d/attachment.html 

From ioi.lam at oracle.com  Wed Aug 21 10:22:30 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 21 Aug 2013 10:22:30 -0700
Subject: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even
	when BUILD_WIN_SA != 1
In-Reply-To: <5214F173.8000208@oracle.com>
References: <5213DB89.6080705@oracle.com> <52144E6D.8080905@oracle.com>
	<5214F173.8000208@oracle.com>
Message-ID: <5214F756.70703@oracle.com>

build-dev folks, any comments?

I have updated the patch to remove the SKIP_GENERATED changes:

http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_002/

Thanks
- Ioi

On 08/21/2013 09:57 AM, Ioi Lam wrote:
> Good catch! I tried to sneak this in :-)
>
> SKIP_GENERATED can be set as an environment variable to skip the 
> 'generated' directory. I have an external script that checks if the 
> file generated/_build_pch_file.cpp already exists. If so, it will set 
> SKIP_GENERATED=1 before calling build.bat. This would save about 20 
> seconds in build time.
>
> I will revert the SKIP_GENERATED change for now and won't commit it, 
> since the may affect the build if someone just happens to have 
> SKIP_GENERATED=1 in their environment variables.
>
> Thanks
>
> - Ioi
>
> On 08/20/2013 10:21 PM, Yumin Qi wrote:
>> Ioi,
>>
>>   One question, SKIP_GENERATED, is this a environment variable or 
>> need to give on command?
>>   Others looks OK.
>>
>> Thanks
>> Yumin
>>
>> On 8/20/2013 2:11 PM, Ioi Lam wrote:
>>> |Please review a very small fix:||
>>> ||
>>> ||http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/|| 
>>>
>>> ||
>>> ||Bug: make/windows/build_vm_def.sh takes too long even when 
>>> BUILD_WIN_SA != 1||
>>> ||
>>> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023406||
>>> ||https://jbs.oracle.com/bugs/browse/JDK-8023406||
>>> ||
>>> ||Summary of fix:||
>>> ||
>>> ||    Reduce Windows build time to improve developer productivity.||
>>> ||
>>> ||    If BUILD_WIN_SA != 1, don't bother to generate vm.def, whose 
>>> sole ||
>>> ||    purpose is for SA to determine the type information of C++ 
>>> objects.||
>>> ||
>>> ||    Instead, this rather eye-catching warning is printed, and 10 
>>> seconds||
>>> ||    are saved in the build cycle.||
>>> ||
>>> ||        ***||
>>> ||        *** Not building SA: BUILD_WIN_SA != 1||
>>> ||        *** C++ Vtables NOT included in vm.def||
>>> ||        *** This jvm.dll will NOT work properly with SA.||
>>> ||        ***||
>>> ||        *** When in doubt, set BUILD_WIN_SA=1, clean and rebuild.||
>>> ||        ***||
>>> ||
>>> ||    This does not affect JPRT -- JPRT always sets BUILD_WIN_SA=1.||
>>> ||
>>> ||Result: ||
>>> ||
>>> ||    Touch 1 .cpp file; rebuild: Total time is reduced 15 seconds 
>>> -> 5 seconds.||
>>> ||
>>> ||Tests:||
>>> ||
>>>     [0] Manual testing with both create.bat (IDE build) and build.bat
>>>         VS 2008 + VS2010
>>> ||    [1] JPRT (windows.* only)||
>>> ||    [2] I built a jvm.dll without BUILD_WIN_SA=0, and it ran 
>>> Eclipsed without||
>>> ||        any problem.||
>>> ||
>>> ||Thanks||
>>> ||- Ioi| 
>>
>


From staffan.larsen at oracle.com  Wed Aug 21 10:45:58 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 21 Aug 2013 19:45:58 +0200
Subject: RFR(XXS): Event based tracing framework needs a mutex for thread
	groups
In-Reply-To: <8fe03bb7-b825-4bf9-835b-d1383c24e329@default>
References: <fb8c00ba-710e-4f81-a20f-03c6e506cd92@default>
	<51260B4E-9542-4BA3-B472-44AB428EA6C6@oracle.com>
	<8fe03bb7-b825-4bf9-835b-d1383c24e329@default>
Message-ID: <12AC552F-6CF0-45DC-8EDE-23C9EE50B5A1@oracle.com>

Looks good!

/Staffan

On 21 aug 2013, at 18:18, Markus Gr?nlund <markus.gronlund at oracle.com> wrote:

> Thanks Karen,
>  
> Based on some feedback, I have updated the naming of this lock and grouped them all inside the INCLUDE_TRACE guard.
>  
> Updated webrev:
> http://cr.openjdk.java.net/~mgronlun/8023457/webrev02/
>  
> Thanks
> Markus
>  
> From: Karen Kinnear 
> Sent: den 21 augusti 2013 17:15
> To: Markus Gr?nlund
> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(XXS): Event based tracing framework needs a mutex for thread groups
>  
> Looks good.
>  
> thanks,
> Karen
>  
> On Aug 21, 2013, at 7:11 AM, Markus Gr?nlund wrote:
> 
> 
> Greetings,
>  
> Kindly asking for reviews for the following:
>  
> Bugid: http://bugs.sun.com/view_bug.do?bug_id=8023457
>  
> Webrev: http://cr.openjdk.java.net/~mgronlun/8023457/webrev01/
>  
> Thanks
> Markus
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130821/97b0cd89/attachment.html 

From calvin.cheung at oracle.com  Wed Aug 21 11:49:58 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Wed, 21 Aug 2013 11:49:58 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5209D002.9090604@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com>
Message-ID: <52150BD6.2090408@oracle.com>

Can someone review this?

Latest version:
http://cr.openjdk.java.net/~ccheung/8020675/webrev/

Previous version without using TRAPS:
http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/

thanks,
Calvin

On 8/12/2013 11:19 PM, Calvin Cheung wrote:
> Hi David,
>
> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a bit 
> more and found that the error was thrown at a very early stage within 
> the init_globals() called from create_vm(). Below is the call stack:
>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
> st, ClassPathEntry * * new_entry, bool lazy)  Line 508    C++
>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
> bytes    C++
>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) Line 
> 322 + 0x8 bytes C++
>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
> __the_thread__)  Line 898 + 0x17 bytes    C++
>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
> class_name, Handle class_loader, Thread * __the_thread__)  Line 1362 + 
> 0x14 bytes    C++
> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
> name, Handle class_loader, Handle protection_domain, Thread * 
> __the_thread__)  Line 758 + 0x18 bytes    C++
>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
> Handle class_loader, Handle protection_domain, Thread * 
> __the_thread__)  Line 206 + 0x15 bytes    C++
>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
> Thread * __the_thread__)  Line 211 + 0x23 bytes    C++
> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    C++
> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
> limit_id, SystemDictionary::WKID & start_id, Thread * __the_thread__)  
> Line 1949 + 0x11 bytes    C++
>      jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
> __the_thread__)  Line 2011 + 0xf bytes    C++
>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
> Line 1904 + 0x9 bytes    C++
>      jvm.dll!Universe::genesis(Thread * __the_thread__)  Line 353 + 
> 0x9 bytes    C++
>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
> >   jvm.dll!init_globals()  Line 114    C++
>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
> canTryAgain)  Line 3220 + 0x5 bytes    C++
>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
> args)  Line 5133 + 0xd bytes    C++
>      java.exe!011013bd()
>      [Frames below may be incorrect and/or missing, no symbols loaded 
> for java.exe]
>      java.exe!01101e2f()
>      java.exe!0110c807()
>      java.exe!0110a5a1()
>      java.exe!0110c845()
>      java.exe!0110a62b()
>      kernel32.dll!767633aa()
>      ntdll.dll!77739ef2()
>      ntdll.dll!77739ec5()
>
> The error was thrown in the method below:
> bool Exceptions::special_exception(Thread* thread, const char* file, 
> int line, Symbol* h_name, const char* message) {
>   // bootstrapping check
>   if (!Universe::is_fully_initialized()) {
>     if (h_name == NULL) {
>       // atleast an informative message.
>       vm_exit_during_initialization("Exception", message);
>     } else {
>       vm_exit_during_initialization(h_name, message);               
> <=====here
>     }
>     ShouldNotReachHere();
>   }
> }
>
> Note that it happened in the early stage during create_vm(), so the 
> (!Universe::is_fully_initialized()) was true.
>
> The class it was trying to load was sun/misc/AtomicLongCSImpl which I 
> couldn't find in 7u25.
> It was going through all the jar files in the bootclasspath and 
> finally got to the foo.jar which has 0-byte and got "error in opening 
> jar file" and then THROW_MSG().
> So I think it's just a coincident in 7u25 where the correct error was 
> thrown.
>
> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class and 
> thus it didn't hit the "error in opening jar file" (for the foo.jar) 
> early until it passed the point when the vm is considered 
> "initialized" - is_init_completed() is true. So when THROW_MSG() was 
> called when it tried to load the class specified by the test case 
> ("xxx"), it triggered the fatal error in ~ExceptionMark(). Call stack 
> up to the THROWN_MSG() as follows:
>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
> st, ClassPathEntry * * new_entry, bool lazy)  Line 508    C++
>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
> bytes    C++
> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  Line 
> 322 + 0x8 bytes    C++
>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
> __the_thread__)  Line 900 + 0x17 bytes C++
>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
> class_name, Handle class_loader, Thread * __the_thread__)  Line 1301 + 
> 0x14 bytes    C++
> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
> name, Handle class_loader, Handle protection_domain, Thread * 
> __the_thread__)  Line 779 + 0x18 bytes    C++
>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
> Handle class_loader, Handle protection_domain, Thread * 
> __the_thread__)  Line 232 + 0x15 bytes    C++
>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
> Thread * __the_thread__)  Line 237 + 0x23 bytes    C++
>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
> name)  Line 773 + 0x12 bytes    C++
>      java.dll!69461e8c()
>      [Frames below may be incorrect and/or missing, no symbols loaded 
> for java.dll]
>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
> elem)  Line 207    C++
>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) Line 
> 375 + 0x11 bytes    C++
>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * thread)  
> Line 40 + 0x9 bytes    C++
>
> I'll try using TRAPS all the way through the call chain probably 
> starting from ClassLoader::load_classfile().
>
> thanks,
> Calvin
>
> On 8/11/2013 10:40 PM, David Holmes wrote:
>> Hi Calvin,
>>
>> I don't think this works. As I said previously the expectations of 
>> this code with regard to Java exceptions seems to be that it doesn't 
>> expect them at all. If you are using TRAPS etc then it should be used 
>> all the way through the call chain. What we have now is this call 
>> sequence:
>>
>> void ClassLoader::initialize() {
>>   assert(_package_hash_table == NULL, "should have been initialized 
>> by now.");
>>   EXCEPTION_MARK;
>>   ...
>>   setup_bootstrap_search_path();
>>     -> update_class_path_entry_list(path, false);
>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>> LazyBootClassLoader, CHECK);
>>
>> So if we return after the call to create_class_path_entry with an 
>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>
>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>> exception check and a vm_exit_during_initialization, if this 
>> exception can readily occur at runtime. But further analysis of all 
>> this code needs to be undertaken.
>>
>> David
>> -----
>>
>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>> I've updated the webrev with 2 changes:
>>> 1) added the TRAPS as the last parameter to the
>>> create_class_path_entry() method;
>>> 2) added a jtreg test case.
>>>
>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>
>>> Please take a look again.
>>>
>>> One more response in-lined below...
>>>
>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>> |I found one version of JDK7 that does not crash:||
>>>> ||
>>>> sc11136754 ~$
>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>
>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>> Error occurred during initialization of VM
>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>> |
>>>
>>> |I noticed that it started breaking in 7u40 b01; it was still working
>>> with 7u25.
>>> It may have something to do with when the set_init_completed() is 
>>> called:
>>> ExceptionMark::~ExceptionMark() {
>>>    if (_thread->has_pending_exception()) {
>>>      Handle exception(_thread, _thread->pending_exception());
>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>> recursion
>>>      if (is_init_completed()) {
>>>        exception->print();
>>>        fatal("ExceptionMark destructor expects no pending exceptions");
>>>      } else {
>>>        vm_exit_during_initialization(exception);
>>>      }
>>>    }
>>> }
>>>
>>> Before 7u40, I think the code path got to the "else" branch of
>>> ~ExceptionMark() and we just printed an error and exit.
>>>
>>> set_init_completed() is only called from Threads::create_vm() and that
>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>> initialization - MemTracker::bootstrap_single_thread(),
>>> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>>>
>>> Debugging with hs25, the set_init_completed() always happened before
>>> create_class_path_entry() and both calls were done within the same
>>> thread - "vm startup".
>>>
>>> thanks,
>>> Calvin
>>>
>>>
>>> |
>>>> |||
>>>> ||
>>>> ||- Ioi
>>>> |
>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>> |I found an official version that's closest to the Redhat version
>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>> crashes.||
>>>>> ||
>>>>> ||sc11136754 ~$
>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>> ||java version "1.6.0_25"||
>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>> ||
>>>>> ||java.lang.ClassNotFoundException ||
>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>> ||#||
>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>> Environment:||
>>>>> ||#||
>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>> tid=140608485558016||
>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>> exceptions||
>>>>> ||#||
>>>>> ||# JRE version: 6.0_25-b06||
>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>>>> linux-amd64 compressed oops)||
>>>>> ||# An error report file with more information is saved as:||
>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>> ||#||
>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>> ||#||
>>>>> ||Aborted (core dumped)||
>>>>> |
>>>>> - Ioi
>>>>>
>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>> apparently
>>>>>>> works differently
>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed this in
>>>>>>> their
>>>>>>> own repo??||
>>>>>>
>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> ||
>>>>>>> |
>>>>>>> |==OEL6================================================
>>>>>>> ||
>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>> ||sc11136754 ~$ type java||
>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>> ||java version "1.6.0_22"||
>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>>>> test2||
>>>>>>> ||Error occurred during initialization of VM||
>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>> foo.jar||
>>>>>>> ||
>>>>>>> ==OFFICIAL============================================
>>>>>>> ||
>>>>>>> sc11136754 ~$ 
>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>> java version "1.6.0_22"
>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>
>>>>>>> #
>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>> #
>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>> tid=140510319580928
>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>> #
>>>>>>> # JRE version: 6.0_22-b04
>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>>>> linux-amd64 )
>>>>>>> # An error report file with more information is saved as:
>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>> #
>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>> #
>>>>>>> |
>>>>>>> |======================================================
>>>>>>> ||
>>>>>>> ||- Ioi|
>>>>>>>
>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>> Hi Ioi, David,
>>>>>>>>
>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>> files in
>>>>>>>>> the JDK:||
>>>>>>>>> ||
>>>>>>>>> ||=========================||
>>>>>>>>> ||/*||
>>>>>>>>> ||javac test2.java||
>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>> ||touch foo.jar||
>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>> ||*/||
>>>>>>>>> ||
>>>>>>>>> ||public class test2 {||
>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>> ||        try {||
>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>> ||        }||
>>>>>>>>> ||    }||
>>>>>>>>> ||}||
>>>>>>>>> ||=========================||
>>>>>>>>> | |
>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second "java 
>>>>>>>>> -cp .
>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>> |
>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>> cases.
>>>>>>>> The crash seems to be at the same spot.
>>>>>>>> |
>>>>>>>>> |||
>>>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior (not
>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>> checking),
>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>> |
>>>>>>>> |I checked the jdk 6 code and those 3 methods which I changed look
>>>>>>>> the
>>>>>>>> same as jdk 8.
>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>> |
>>>>>>>>> |||
>>>>>>>>> ||Thanks||
>>>>>>>>> ||- Ioi||
>>>>>>>>> ||
>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>> |
>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>> | |
>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>>>> declared with a last parameter of TRAPS and called with a CHECK_
>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>> expect any
>>>>>>>>>> exceptions to be possible. I would check with Karen on this. ||
>>>>>>>>>> |
>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>> changes.
>>>>>>>> I can give it a try.
>>>>>>>> |
>>>>>>>>>> || |
>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>> | |
>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>> |
>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>> It won't be needed if the method is declared with TRAPS as the 
>>>>>>>> last
>>>>>>>> parameter (I think).
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Calvin
>>>>>>>> |
>>>>>>>>>> || |
>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>> throwing
>>>>>>>>>> exceptions - don't know what the thought process was there :) ||
>>>>>>>>>> | |
>>>>>>>>>> ||David ||
>>>>>>>>>> | |
>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>> |
>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>> similar
>>>>>>>>>>> crash ||
>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>> the ||
>>>>>>>>>>> ||bootclasspath. The following program can trigger the crash if
>>>>>>>>>>> the ||
>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>> ||         try { ||
>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>> ||         } ||
>>>>>>>>>>> ||     } ||
>>>>>>>>>>> ||} ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>>>>>>>> above test ||
>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>> thrown ||
>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>> ||         at
>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>> ||         at
>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>> ||         at 
>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>> Method) ||
>>>>>>>>>>> ||         at
>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>>>> ||         at
>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>> ||         at
>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) || 
>>>>>>>>>>>
>>>>>>>>>>> ||         at
>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>> | |
>>>>>>>>>>> | |
>>>>>>>>>>> |
>>>>>>>>> |
>>>>>>>>> |
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>


From chris.plummer at oracle.com  Wed Aug 21 12:12:33 2013
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 21 Aug 2013 12:12:33 -0700
Subject: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on platforms
	if NMT detail is not supported
In-Reply-To: <52141E03.3060003@oracle.com>
References: <5213C483.1060102@oracle.com> <5214173C.7000806@oracle.com>
	<52141C39.3070509@oracle.com> <52141E03.3060003@oracle.com>
Message-ID: <52151121.1020906@oracle.com>

New webrev posted. The only change from the previous one is dropping the 
Platform.java changes.

http://cr.openjdk.java.net/~cjplummer/8020829/webrev-04/

thanks,

Chris

On 8/20/13 6:55 PM, David Holmes wrote:
> On 21/08/2013 11:47 AM, Chris Plummer wrote:
>> On 8/20/13 6:26 PM, David Holmes wrote:
>>> Hi Chris,
>>>
>>> On 21/08/2013 5:33 AM, Chris Plummer wrote:
>>>> https://jbs.oracle.com/bugs/browse/JDK-8020829
>>>> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-03/
>>>>
>>>> On some platforms, NMT detail is not supported, and this was causing
>>>> some jtreg tests to fail. These tests now query a new WhiteBox API to
>>>> see if NMT detail is supported, and now behave properly if it is not
>>>> supported.
>>>
>>> Okay.
>>>
>>>> I also fixed #ifdef INCLUDE_NMT in whitebox.cpp that should instead be
>>>> #if INCLUDE_NMT. The source within the #if is now properly excluded 
>>>> from
>>>> minimal VM builds.
>>>
>>> Okay.
>>>
>>>> The addition of Platform.isArm() is to support changes in closed 
>>>> source.
>>>
>>> I hate seeing these kinds of methods. Add a new platform, add a new
>>> method - yuck! :(
>>>
>>> We could just use getOsArch().toLowerCase().startsWith("arm") directly.
>>>
>>> I'd even prefer to see:
>>>
>>> boolean isArch(String arch) {
>>>   return osArch.toLowerCase().startsWith(arch.toLowerCase());
>>> }
>>>
>>> and similarly for the OS - but that is going beyond this fix :)
>> I'm not particularly tied to any specific way of doing this. I can do
>> either of the above if you wish. Just let me know your preference.
>
> Drop isArm() please and change the closed usage to 
> getOsArch().toLowerCase().startsWith("arm").
>
> I'll file a RFE for Platform :)
>
> Thanks,
> David
>
>> Chris
>>>
>>> Thanks,
>>> David
>>>
>>>> Testing was done using the existing NMT tests, verifying that they now
>>>> pass on platforms where NMT detail is not supported, and still pass on
>>>> platforms where NMT detail is supported. A jprt job is currently in 
>>>> the
>>>> queue to run all NMT jtreg tests on all platforms supported by jprt.
>>>>
>>>> Thanks!
>>>>
>>>> Chris Plummer
>>


From yumin.qi at oracle.com  Wed Aug 21 12:29:08 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 21 Aug 2013 12:29:08 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52150BD6.2090408@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
Message-ID: <52151504.7030408@oracle.com>

Not a review, only a suggestion, the bug description should be modified. 
Confused.

Yumin

On 8/21/2013 11:49 AM, Calvin Cheung wrote:
> Can someone review this?
>
> Latest version:
> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>
> Previous version without using TRAPS:
> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>
> thanks,
> Calvin
>
> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>> Hi David,
>>
>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>> bit more and found that the error was thrown at a very early stage 
>> within the init_globals() called from create_vm(). Below is the call 
>> stack:
>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>> bytes    C++
>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) Line 
>> 322 + 0x8 bytes C++
>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>> class_name, Handle class_loader, Thread * __the_thread__)  Line 1362 
>> + 0x14 bytes    C++
>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>> name, Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 206 + 0x15 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
>> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    C++
>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
>> Line 1904 + 0x9 bytes    C++
>>      jvm.dll!Universe::genesis(Thread * __the_thread__)  Line 353 + 
>> 0x9 bytes    C++
>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
>> >   jvm.dll!init_globals()  Line 114    C++
>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
>> args)  Line 5133 + 0xd bytes    C++
>>      java.exe!011013bd()
>>      [Frames below may be incorrect and/or missing, no symbols loaded 
>> for java.exe]
>>      java.exe!01101e2f()
>>      java.exe!0110c807()
>>      java.exe!0110a5a1()
>>      java.exe!0110c845()
>>      java.exe!0110a62b()
>>      kernel32.dll!767633aa()
>>      ntdll.dll!77739ef2()
>>      ntdll.dll!77739ec5()
>>
>> The error was thrown in the method below:
>> bool Exceptions::special_exception(Thread* thread, const char* file, 
>> int line, Symbol* h_name, const char* message) {
>>   // bootstrapping check
>>   if (!Universe::is_fully_initialized()) {
>>     if (h_name == NULL) {
>>       // atleast an informative message.
>>       vm_exit_during_initialization("Exception", message);
>>     } else {
>>       vm_exit_during_initialization(h_name, message);               
>> <=====here
>>     }
>>     ShouldNotReachHere();
>>   }
>> }
>>
>> Note that it happened in the early stage during create_vm(), so the 
>> (!Universe::is_fully_initialized()) was true.
>>
>> The class it was trying to load was sun/misc/AtomicLongCSImpl which I 
>> couldn't find in 7u25.
>> It was going through all the jar files in the bootclasspath and 
>> finally got to the foo.jar which has 0-byte and got "error in opening 
>> jar file" and then THROW_MSG().
>> So I think it's just a coincident in 7u25 where the correct error was 
>> thrown.
>>
>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>> and thus it didn't hit the "error in opening jar file" (for the 
>> foo.jar) early until it passed the point when the vm is considered 
>> "initialized" - is_init_completed() is true. So when THROW_MSG() was 
>> called when it tried to load the class specified by the test case 
>> ("xxx"), it triggered the fatal error in ~ExceptionMark(). Call stack 
>> up to the THROWN_MSG() as follows:
>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>> bytes    C++
>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  Line 
>> 322 + 0x8 bytes    C++
>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>> __the_thread__)  Line 900 + 0x17 bytes C++
>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>> class_name, Handle class_loader, Thread * __the_thread__)  Line 1301 
>> + 0x14 bytes    C++
>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>> name, Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>> name)  Line 773 + 0x12 bytes    C++
>>      java.dll!69461e8c()
>>      [Frames below may be incorrect and/or missing, no symbols loaded 
>> for java.dll]
>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>> elem)  Line 207    C++
>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>> Line 375 + 0x11 bytes    C++
>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * thread)  
>> Line 40 + 0x9 bytes    C++
>>
>> I'll try using TRAPS all the way through the call chain probably 
>> starting from ClassLoader::load_classfile().
>>
>> thanks,
>> Calvin
>>
>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>> Hi Calvin,
>>>
>>> I don't think this works. As I said previously the expectations of 
>>> this code with regard to Java exceptions seems to be that it doesn't 
>>> expect them at all. If you are using TRAPS etc then it should be 
>>> used all the way through the call chain. What we have now is this 
>>> call sequence:
>>>
>>> void ClassLoader::initialize() {
>>>   assert(_package_hash_table == NULL, "should have been initialized 
>>> by now.");
>>>   EXCEPTION_MARK;
>>>   ...
>>>   setup_bootstrap_search_path();
>>>     -> update_class_path_entry_list(path, false);
>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>> LazyBootClassLoader, CHECK);
>>>
>>> So if we return after the call to create_class_path_entry with an 
>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>
>>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>>> exception check and a vm_exit_during_initialization, if this 
>>> exception can readily occur at runtime. But further analysis of all 
>>> this code needs to be undertaken.
>>>
>>> David
>>> -----
>>>
>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>> I've updated the webrev with 2 changes:
>>>> 1) added the TRAPS as the last parameter to the
>>>> create_class_path_entry() method;
>>>> 2) added a jtreg test case.
>>>>
>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>
>>>> Please take a look again.
>>>>
>>>> One more response in-lined below...
>>>>
>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>> |I found one version of JDK7 that does not crash:||
>>>>> ||
>>>>> sc11136754 ~$
>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>
>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>> Error occurred during initialization of VM
>>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>>> |
>>>>
>>>> |I noticed that it started breaking in 7u40 b01; it was still working
>>>> with 7u25.
>>>> It may have something to do with when the set_init_completed() is 
>>>> called:
>>>> ExceptionMark::~ExceptionMark() {
>>>>    if (_thread->has_pending_exception()) {
>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>> recursion
>>>>      if (is_init_completed()) {
>>>>        exception->print();
>>>>        fatal("ExceptionMark destructor expects no pending 
>>>> exceptions");
>>>>      } else {
>>>>        vm_exit_during_initialization(exception);
>>>>      }
>>>>    }
>>>> }
>>>>
>>>> Before 7u40, I think the code path got to the "else" branch of
>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>
>>>> set_init_completed() is only called from Threads::create_vm() and that
>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>>>>
>>>> Debugging with hs25, the set_init_completed() always happened before
>>>> create_class_path_entry() and both calls were done within the same
>>>> thread - "vm startup".
>>>>
>>>> thanks,
>>>> Calvin
>>>>
>>>>
>>>> |
>>>>> |||
>>>>> ||
>>>>> ||- Ioi
>>>>> |
>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>> |I found an official version that's closest to the Redhat version
>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>> crashes.||
>>>>>> ||
>>>>>> ||sc11136754 ~$
>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>> ||java version "1.6.0_25"||
>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>> ||
>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>> ||#||
>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>> Environment:||
>>>>>> ||#||
>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>> tid=140608485558016||
>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>> exceptions||
>>>>>> ||#||
>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>>>>> linux-amd64 compressed oops)||
>>>>>> ||# An error report file with more information is saved as:||
>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>> ||#||
>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>> ||#||
>>>>>> ||Aborted (core dumped)||
>>>>>> |
>>>>>> - Ioi
>>>>>>
>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>> apparently
>>>>>>>> works differently
>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed this in
>>>>>>>> their
>>>>>>>> own repo??||
>>>>>>>
>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> ||
>>>>>>>> |
>>>>>>>> |==OEL6================================================
>>>>>>>> ||
>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>>>>> test2||
>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>> foo.jar||
>>>>>>>> ||
>>>>>>>> ==OFFICIAL============================================
>>>>>>>> ||
>>>>>>>> sc11136754 ~$ 
>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>> java version "1.6.0_22"
>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>
>>>>>>>> #
>>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>>> #
>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>> tid=140510319580928
>>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>>> #
>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>>>>> linux-amd64 )
>>>>>>>> # An error report file with more information is saved as:
>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>> #
>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>> #
>>>>>>>> |
>>>>>>>> |======================================================
>>>>>>>> ||
>>>>>>>> ||- Ioi|
>>>>>>>>
>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>> Hi Ioi, David,
>>>>>>>>>
>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>> files in
>>>>>>>>>> the JDK:||
>>>>>>>>>> ||
>>>>>>>>>> ||=========================||
>>>>>>>>>> ||/*||
>>>>>>>>>> ||javac test2.java||
>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>> ||*/||
>>>>>>>>>> ||
>>>>>>>>>> ||public class test2 {||
>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>> ||        try {||
>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>> ||        }||
>>>>>>>>>> ||    }||
>>>>>>>>>> ||}||
>>>>>>>>>> ||=========================||
>>>>>>>>>> | |
>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second "java 
>>>>>>>>>> -cp .
>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>> |
>>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>>> cases.
>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>> |
>>>>>>>>>> |||
>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior 
>>>>>>>>>> (not
>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>> checking),
>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>> |
>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I changed 
>>>>>>>>> look
>>>>>>>>> the
>>>>>>>>> same as jdk 8.
>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>> |
>>>>>>>>>> |||
>>>>>>>>>> ||Thanks||
>>>>>>>>>> ||- Ioi||
>>>>>>>>>> ||
>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>> |
>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>> CHECK_
>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>> expect any
>>>>>>>>>>> exceptions to be possible. I would check with Karen on this. ||
>>>>>>>>>>> |
>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>> changes.
>>>>>>>>> I can give it a try.
>>>>>>>>> |
>>>>>>>>>>> || |
>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>> |
>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>> It won't be needed if the method is declared with TRAPS as the 
>>>>>>>>> last
>>>>>>>>> parameter (I think).
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> Calvin
>>>>>>>>> |
>>>>>>>>>>> || |
>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>>> throwing
>>>>>>>>>>> exceptions - don't know what the thought process was there 
>>>>>>>>>>> :) ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||David ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>> |
>>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>> similar
>>>>>>>>>>>> crash ||
>>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>>> the ||
>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>> crash if
>>>>>>>>>>>> the ||
>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>> ||} ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>>>>>>>>> above test ||
>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>>> thrown ||
>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>> ||         at 
>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>> Method) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>> ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> | |
>>>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>


From tim.bell at oracle.com  Wed Aug 21 12:34:35 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 21 Aug 2013 12:34:35 -0700
Subject: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even
	when BUILD_WIN_SA != 1
In-Reply-To: <5214F756.70703@oracle.com>
References: <5213DB89.6080705@oracle.com> <52144E6D.8080905@oracle.com>
	<5214F173.8000208@oracle.com> <5214F756.70703@oracle.com>
Message-ID: <5215164B.2080704@oracle.com>

Hello Ioi:

> build-dev folks, any comments?
>
> I have updated the patch to remove the SKIP_GENERATED changes:
>
> http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_002/

make/windows/build_vm_def.sh

Seems as if line 86:

86 "$CAT" vm1.def vm2.def > vm.def

Will clobber the friendly message written out to vm.def in lines 56 ... 58

Perhaps you meant to write to vm1.def in lines 56 ... 58 and also put 
line 70 inside an else ... fi block?

Also, I am not sure what you want to do with vm2.def in the "-nosa" case.


make/windows/makefiles/debug.make
no comments

make/windows/makefiles/fastdebug.make
no comments

make/windows/makefiles/product.make
no comments

make/windows/makefiles/projectcreator.make
no comments

make/windows/makefiles/vm.make
no comments

Tim

> Thanks
> - Ioi
>
> On 08/21/2013 09:57 AM, Ioi Lam wrote:
>> Good catch! I tried to sneak this in :-)
>>
>> SKIP_GENERATED can be set as an environment variable to skip the 
>> 'generated' directory. I have an external script that checks if the 
>> file generated/_build_pch_file.cpp already exists. If so, it will set 
>> SKIP_GENERATED=1 before calling build.bat. This would save about 20 
>> seconds in build time.
>>
>> I will revert the SKIP_GENERATED change for now and won't commit it, 
>> since the may affect the build if someone just happens to have 
>> SKIP_GENERATED=1 in their environment variables.
>>
>> Thanks
>>
>> - Ioi
>>
>> On 08/20/2013 10:21 PM, Yumin Qi wrote:
>>> Ioi,
>>>
>>>   One question, SKIP_GENERATED, is this a environment variable or 
>>> need to give on command?
>>>   Others looks OK.
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 8/20/2013 2:11 PM, Ioi Lam wrote:
>>>> |Please review a very small fix:||
>>>> ||
>>>> ||http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/|| 
>>>>
>>>> ||
>>>> ||Bug: make/windows/build_vm_def.sh takes too long even when 
>>>> BUILD_WIN_SA != 1||
>>>> ||
>>>> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023406||
>>>> ||https://jbs.oracle.com/bugs/browse/JDK-8023406||
>>>> ||
>>>> ||Summary of fix:||
>>>> ||
>>>> ||    Reduce Windows build time to improve developer productivity.||
>>>> ||
>>>> ||    If BUILD_WIN_SA != 1, don't bother to generate vm.def, whose 
>>>> sole ||
>>>> ||    purpose is for SA to determine the type information of C++ 
>>>> objects.||
>>>> ||
>>>> ||    Instead, this rather eye-catching warning is printed, and 10 
>>>> seconds||
>>>> ||    are saved in the build cycle.||
>>>> ||
>>>> ||        ***||
>>>> ||        *** Not building SA: BUILD_WIN_SA != 1||
>>>> ||        *** C++ Vtables NOT included in vm.def||
>>>> ||        *** This jvm.dll will NOT work properly with SA.||
>>>> ||        ***||
>>>> ||        *** When in doubt, set BUILD_WIN_SA=1, clean and rebuild.||
>>>> ||        ***||
>>>> ||
>>>> ||    This does not affect JPRT -- JPRT always sets BUILD_WIN_SA=1.||
>>>> ||
>>>> ||Result: ||
>>>> ||
>>>> ||    Touch 1 .cpp file; rebuild: Total time is reduced 15 seconds 
>>>> -> 5 seconds.||
>>>> ||
>>>> ||Tests:||
>>>> ||
>>>>     [0] Manual testing with both create.bat (IDE build) and build.bat
>>>>         VS 2008 + VS2010
>>>> ||    [1] JPRT (windows.* only)||
>>>> ||    [2] I built a jvm.dll without BUILD_WIN_SA=0, and it ran 
>>>> Eclipsed without||
>>>> ||        any problem.||
>>>> ||
>>>> ||Thanks||
>>>> ||- Ioi| 
>>>
>>
>


From tim.bell at oracle.com  Wed Aug 21 12:44:29 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 21 Aug 2013 12:44:29 -0700
Subject: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even
	when BUILD_WIN_SA != 1
In-Reply-To: <5215164B.2080704@oracle.com>
References: <5213DB89.6080705@oracle.com> <52144E6D.8080905@oracle.com>
	<5214F173.8000208@oracle.com> <5214F756.70703@oracle.com>
	<5215164B.2080704@oracle.com>
Message-ID: <5215189D.9040509@oracle.com>

On 08/21/13 12:34 PM, Tim Bell wrote:
> Hello Ioi:
>
>> build-dev folks, any comments?
>>
>> I have updated the patch to remove the SKIP_GENERATED changes:
>>
>> http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_002/
>
> make/windows/build_vm_def.sh
>
> Seems as if line 86:
>
> 86 "$CAT" vm1.def vm2.def > vm.def
>
> Will clobber the friendly message written out to vm.def in lines 56 
> ... 58

nevermind - I just spotted line 67:

67     exit

So the remainder of build_vm_def.sh is not run in this case.

Approved...

Tim


>
> Perhaps you meant to write to vm1.def in lines 56 ... 58 and also put 
> line 70 inside an else ... fi block?
>
> Also, I am not sure what you want to do with vm2.def in the "-nosa" case.
>
>
> make/windows/makefiles/debug.make
> no comments
>
> make/windows/makefiles/fastdebug.make
> no comments
>
> make/windows/makefiles/product.make
> no comments
>
> make/windows/makefiles/projectcreator.make
> no comments
>
> make/windows/makefiles/vm.make
> no comments
>
> Tim
>
>> Thanks
>> - Ioi
>>
>> On 08/21/2013 09:57 AM, Ioi Lam wrote:
>>> Good catch! I tried to sneak this in :-)
>>>
>>> SKIP_GENERATED can be set as an environment variable to skip the 
>>> 'generated' directory. I have an external script that checks if the 
>>> file generated/_build_pch_file.cpp already exists. If so, it will 
>>> set SKIP_GENERATED=1 before calling build.bat. This would save about 
>>> 20 seconds in build time.
>>>
>>> I will revert the SKIP_GENERATED change for now and won't commit it, 
>>> since the may affect the build if someone just happens to have 
>>> SKIP_GENERATED=1 in their environment variables.
>>>
>>> Thanks
>>>
>>> - Ioi
>>>
>>> On 08/20/2013 10:21 PM, Yumin Qi wrote:
>>>> Ioi,
>>>>
>>>>   One question, SKIP_GENERATED, is this a environment variable or 
>>>> need to give on command?
>>>>   Others looks OK.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>> On 8/20/2013 2:11 PM, Ioi Lam wrote:
>>>>> |Please review a very small fix:||
>>>>> ||
>>>>> ||http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/|| 
>>>>>
>>>>> ||
>>>>> ||Bug: make/windows/build_vm_def.sh takes too long even when 
>>>>> BUILD_WIN_SA != 1||
>>>>> ||
>>>>> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023406||
>>>>> ||https://jbs.oracle.com/bugs/browse/JDK-8023406||
>>>>> ||
>>>>> ||Summary of fix:||
>>>>> ||
>>>>> ||    Reduce Windows build time to improve developer productivity.||
>>>>> ||
>>>>> ||    If BUILD_WIN_SA != 1, don't bother to generate vm.def, whose 
>>>>> sole ||
>>>>> ||    purpose is for SA to determine the type information of C++ 
>>>>> objects.||
>>>>> ||
>>>>> ||    Instead, this rather eye-catching warning is printed, and 10 
>>>>> seconds||
>>>>> ||    are saved in the build cycle.||
>>>>> ||
>>>>> ||        ***||
>>>>> ||        *** Not building SA: BUILD_WIN_SA != 1||
>>>>> ||        *** C++ Vtables NOT included in vm.def||
>>>>> ||        *** This jvm.dll will NOT work properly with SA.||
>>>>> ||        ***||
>>>>> ||        *** When in doubt, set BUILD_WIN_SA=1, clean and rebuild.||
>>>>> ||        ***||
>>>>> ||
>>>>> ||    This does not affect JPRT -- JPRT always sets BUILD_WIN_SA=1.||
>>>>> ||
>>>>> ||Result: ||
>>>>> ||
>>>>> ||    Touch 1 .cpp file; rebuild: Total time is reduced 15 seconds 
>>>>> -> 5 seconds.||
>>>>> ||
>>>>> ||Tests:||
>>>>> ||
>>>>>     [0] Manual testing with both create.bat (IDE build) and build.bat
>>>>>         VS 2008 + VS2010
>>>>> ||    [1] JPRT (windows.* only)||
>>>>> ||    [2] I built a jvm.dll without BUILD_WIN_SA=0, and it ran 
>>>>> Eclipsed without||
>>>>> ||        any problem.||
>>>>> ||
>>>>> ||Thanks||
>>>>> ||- Ioi| 
>>>>
>>>
>>
>


From daniel.daugherty at oracle.com  Wed Aug 21 13:14:12 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 21 Aug 2013 14:14:12 -0600
Subject: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even
	when BUILD_WIN_SA != 1
In-Reply-To: <5214F756.70703@oracle.com>
References: <5213DB89.6080705@oracle.com> <52144E6D.8080905@oracle.com>
	<5214F173.8000208@oracle.com> <5214F756.70703@oracle.com>
Message-ID: <52151F94.3030201@oracle.com>

On 8/21/13 11:22 AM, Ioi Lam wrote:
> build-dev folks, any comments?
>
> I have updated the patch to remove the SKIP_GENERATED changes:
>
> http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_002/

Thumbs up.

make/windows/build_vm_def.sh
     No comments.

make/windows/makefiles/debug.make
make/windows/makefiles/fastdebug.make
  make/windows/makefiles/product.make
     Deleted vm.def rule in these three. OK.

make/windows/makefiles/projectcreator.make
Adds and uses new BUILD_VM_DEF_FLAG. Looks good.

make/windows/makefiles/vm.make
     vm.def rule moved here. Adds and uses new BUILD_VM_DEF_FLAG.
     Looks good.

Dan


>
> Thanks
> - Ioi
>
> On 08/21/2013 09:57 AM, Ioi Lam wrote:
>> Good catch! I tried to sneak this in :-)
>>
>> SKIP_GENERATED can be set as an environment variable to skip the 
>> 'generated' directory. I have an external script that checks if the 
>> file generated/_build_pch_file.cpp already exists. If so, it will set 
>> SKIP_GENERATED=1 before calling build.bat. This would save about 20 
>> seconds in build time.
>>
>> I will revert the SKIP_GENERATED change for now and won't commit it, 
>> since the may affect the build if someone just happens to have 
>> SKIP_GENERATED=1 in their environment variables.
>>
>> Thanks
>>
>> - Ioi
>>
>> On 08/20/2013 10:21 PM, Yumin Qi wrote:
>>> Ioi,
>>>
>>>   One question, SKIP_GENERATED, is this a environment variable or 
>>> need to give on command?
>>>   Others looks OK.
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 8/20/2013 2:11 PM, Ioi Lam wrote:
>>>> |Please review a very small fix:||
>>>> ||
>>>> ||http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/|| 
>>>>
>>>> ||
>>>> ||Bug: make/windows/build_vm_def.sh takes too long even when 
>>>> BUILD_WIN_SA != 1||
>>>> ||
>>>> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023406||
>>>> ||https://jbs.oracle.com/bugs/browse/JDK-8023406||
>>>> ||
>>>> ||Summary of fix:||
>>>> ||
>>>> ||    Reduce Windows build time to improve developer productivity.||
>>>> ||
>>>> ||    If BUILD_WIN_SA != 1, don't bother to generate vm.def, whose 
>>>> sole ||
>>>> ||    purpose is for SA to determine the type information of C++ 
>>>> objects.||
>>>> ||
>>>> ||    Instead, this rather eye-catching warning is printed, and 10 
>>>> seconds||
>>>> ||    are saved in the build cycle.||
>>>> ||
>>>> ||        ***||
>>>> ||        *** Not building SA: BUILD_WIN_SA != 1||
>>>> ||        *** C++ Vtables NOT included in vm.def||
>>>> ||        *** This jvm.dll will NOT work properly with SA.||
>>>> ||        ***||
>>>> ||        *** When in doubt, set BUILD_WIN_SA=1, clean and rebuild.||
>>>> ||        ***||
>>>> ||
>>>> ||    This does not affect JPRT -- JPRT always sets BUILD_WIN_SA=1.||
>>>> ||
>>>> ||Result: ||
>>>> ||
>>>> ||    Touch 1 .cpp file; rebuild: Total time is reduced 15 seconds 
>>>> -> 5 seconds.||
>>>> ||
>>>> ||Tests:||
>>>> ||
>>>>     [0] Manual testing with both create.bat (IDE build) and build.bat
>>>>         VS 2008 + VS2010
>>>> ||    [1] JPRT (windows.* only)||
>>>> ||    [2] I built a jvm.dll without BUILD_WIN_SA=0, and it ran 
>>>> Eclipsed without||
>>>> ||        any problem.||
>>>> ||
>>>> ||Thanks||
>>>> ||- Ioi| 
>>>
>>
>


From calvin.cheung at oracle.com  Wed Aug 21 13:21:05 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Wed, 21 Aug 2013 13:21:05 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52151504.7030408@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
	<52151504.7030408@oracle.com>
Message-ID: <52152131.4080204@oracle.com>

I was thinking about updating the bug synopsis.
How about the following?
invalid jar file in the bootclasspath can lead to jvm fatal error

Calvin

On 8/21/2013 12:29 PM, Yumin Qi wrote:
> Not a review, only a suggestion, the bug description should be 
> modified. Confused.
>
> Yumin
>
> On 8/21/2013 11:49 AM, Calvin Cheung wrote:
>> Can someone review this?
>>
>> Latest version:
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>
>> Previous version without using TRAPS:
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>>
>> thanks,
>> Calvin
>>
>> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>>> Hi David,
>>>
>>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>>> bit more and found that the error was thrown at a very early stage 
>>> within the init_globals() called from create_vm(). Below is the call 
>>> stack:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>> bytes    C++
>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) Line 
>>> 322 + 0x8 bytes C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1362 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 206 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
>>> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    
>>> C++
>>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
>>> Line 1904 + 0x9 bytes    C++
>>>      jvm.dll!Universe::genesis(Thread * __the_thread__)  Line 353 + 
>>> 0x9 bytes    C++
>>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
>>> >   jvm.dll!init_globals()  Line 114    C++
>>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
>>> args)  Line 5133 + 0xd bytes    C++
>>>      java.exe!011013bd()
>>>      [Frames below may be incorrect and/or missing, no symbols 
>>> loaded for java.exe]
>>>      java.exe!01101e2f()
>>>      java.exe!0110c807()
>>>      java.exe!0110a5a1()
>>>      java.exe!0110c845()
>>>      java.exe!0110a62b()
>>>      kernel32.dll!767633aa()
>>>      ntdll.dll!77739ef2()
>>>      ntdll.dll!77739ec5()
>>>
>>> The error was thrown in the method below:
>>> bool Exceptions::special_exception(Thread* thread, const char* file, 
>>> int line, Symbol* h_name, const char* message) {
>>>   // bootstrapping check
>>>   if (!Universe::is_fully_initialized()) {
>>>     if (h_name == NULL) {
>>>       // atleast an informative message.
>>>       vm_exit_during_initialization("Exception", message);
>>>     } else {
>>>       vm_exit_during_initialization(h_name, message);               
>>> <=====here
>>>     }
>>>     ShouldNotReachHere();
>>>   }
>>> }
>>>
>>> Note that it happened in the early stage during create_vm(), so the 
>>> (!Universe::is_fully_initialized()) was true.
>>>
>>> The class it was trying to load was sun/misc/AtomicLongCSImpl which 
>>> I couldn't find in 7u25.
>>> It was going through all the jar files in the bootclasspath and 
>>> finally got to the foo.jar which has 0-byte and got "error in 
>>> opening jar file" and then THROW_MSG().
>>> So I think it's just a coincident in 7u25 where the correct error 
>>> was thrown.
>>>
>>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>>> and thus it didn't hit the "error in opening jar file" (for the 
>>> foo.jar) early until it passed the point when the vm is considered 
>>> "initialized" - is_init_completed() is true. So when THROW_MSG() was 
>>> called when it tried to load the class specified by the test case 
>>> ("xxx"), it triggered the fatal error in ~ExceptionMark(). Call 
>>> stack up to the THROWN_MSG() as follows:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>> bytes    C++
>>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  
>>> Line 322 + 0x8 bytes    C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 900 + 0x17 bytes C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1301 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>>> name)  Line 773 + 0x12 bytes    C++
>>>      java.dll!69461e8c()
>>>      [Frames below may be incorrect and/or missing, no symbols 
>>> loaded for java.dll]
>>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>>> elem)  Line 207    C++
>>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>>> Line 375 + 0x11 bytes    C++
>>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * 
>>> thread)  Line 40 + 0x9 bytes    C++
>>>
>>> I'll try using TRAPS all the way through the call chain probably 
>>> starting from ClassLoader::load_classfile().
>>>
>>> thanks,
>>> Calvin
>>>
>>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>>> Hi Calvin,
>>>>
>>>> I don't think this works. As I said previously the expectations of 
>>>> this code with regard to Java exceptions seems to be that it 
>>>> doesn't expect them at all. If you are using TRAPS etc then it 
>>>> should be used all the way through the call chain. What we have now 
>>>> is this call sequence:
>>>>
>>>> void ClassLoader::initialize() {
>>>>   assert(_package_hash_table == NULL, "should have been initialized 
>>>> by now.");
>>>>   EXCEPTION_MARK;
>>>>   ...
>>>>   setup_bootstrap_search_path();
>>>>     -> update_class_path_entry_list(path, false);
>>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>>> LazyBootClassLoader, CHECK);
>>>>
>>>> So if we return after the call to create_class_path_entry with an 
>>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>>
>>>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>>>> exception check and a vm_exit_during_initialization, if this 
>>>> exception can readily occur at runtime. But further analysis of all 
>>>> this code needs to be undertaken.
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>>> I've updated the webrev with 2 changes:
>>>>> 1) added the TRAPS as the last parameter to the
>>>>> create_class_path_entry() method;
>>>>> 2) added a jtreg test case.
>>>>>
>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>
>>>>> Please take a look again.
>>>>>
>>>>> One more response in-lined below...
>>>>>
>>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>>> |I found one version of JDK7 that does not crash:||
>>>>>> ||
>>>>>> sc11136754 ~$
>>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>>
>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>> Error occurred during initialization of VM
>>>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>>>> |
>>>>>
>>>>> |I noticed that it started breaking in 7u40 b01; it was still working
>>>>> with 7u25.
>>>>> It may have something to do with when the set_init_completed() is 
>>>>> called:
>>>>> ExceptionMark::~ExceptionMark() {
>>>>>    if (_thread->has_pending_exception()) {
>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>> recursion
>>>>>      if (is_init_completed()) {
>>>>>        exception->print();
>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>> exceptions");
>>>>>      } else {
>>>>>        vm_exit_during_initialization(exception);
>>>>>      }
>>>>>    }
>>>>> }
>>>>>
>>>>> Before 7u40, I think the code path got to the "else" branch of
>>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>>
>>>>> set_init_completed() is only called from Threads::create_vm() and 
>>>>> that
>>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>>>>>
>>>>> Debugging with hs25, the set_init_completed() always happened before
>>>>> create_class_path_entry() and both calls were done within the same
>>>>> thread - "vm startup".
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>>
>>>>> |
>>>>>> |||
>>>>>> ||
>>>>>> ||- Ioi
>>>>>> |
>>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>>> |I found an official version that's closest to the Redhat version
>>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>>> crashes.||
>>>>>>> ||
>>>>>>> ||sc11136754 ~$
>>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>> ||java version "1.6.0_25"||
>>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>> ||
>>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>>> ||#||
>>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>>> Environment:||
>>>>>>> ||#||
>>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>>> tid=140608485558016||
>>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>>> exceptions||
>>>>>>> ||#||
>>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>>>>>> linux-amd64 compressed oops)||
>>>>>>> ||# An error report file with more information is saved as:||
>>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>>> ||#||
>>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>>> ||#||
>>>>>>> ||Aborted (core dumped)||
>>>>>>> |
>>>>>>> - Ioi
>>>>>>>
>>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>>> apparently
>>>>>>>>> works differently
>>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed 
>>>>>>>>> this in
>>>>>>>>> their
>>>>>>>>> own repo??||
>>>>>>>>
>>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> ||
>>>>>>>>> |
>>>>>>>>> |==OEL6================================================
>>>>>>>>> ||
>>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>>>>>> test2||
>>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>>> foo.jar||
>>>>>>>>> ||
>>>>>>>>> ==OFFICIAL============================================
>>>>>>>>> ||
>>>>>>>>> sc11136754 ~$ 
>>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>>> java version "1.6.0_22"
>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>>
>>>>>>>>> #
>>>>>>>>> # A fatal error has been detected by the Java Runtime 
>>>>>>>>> Environment:
>>>>>>>>> #
>>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>>> tid=140510319580928
>>>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>>>> #
>>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>>>>>> linux-amd64 )
>>>>>>>>> # An error report file with more information is saved as:
>>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>>> #
>>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>>> #
>>>>>>>>> |
>>>>>>>>> |======================================================
>>>>>>>>> ||
>>>>>>>>> ||- Ioi|
>>>>>>>>>
>>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>>> Hi Ioi, David,
>>>>>>>>>>
>>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>>> files in
>>>>>>>>>>> the JDK:||
>>>>>>>>>>> ||
>>>>>>>>>>> ||=========================||
>>>>>>>>>>> ||/*||
>>>>>>>>>>> ||javac test2.java||
>>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>> ||*/||
>>>>>>>>>>> ||
>>>>>>>>>>> ||public class test2 {||
>>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>>> ||        try {||
>>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>>> ||        }||
>>>>>>>>>>> ||    }||
>>>>>>>>>>> ||}||
>>>>>>>>>>> ||=========================||
>>>>>>>>>>> | |
>>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second 
>>>>>>>>>>> "java -cp .
>>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>>> |
>>>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>>>> cases.
>>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>>> |
>>>>>>>>>>> |||
>>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior 
>>>>>>>>>>> (not
>>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>>> checking),
>>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>>> |
>>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I changed 
>>>>>>>>>> look
>>>>>>>>>> the
>>>>>>>>>> same as jdk 8.
>>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>>> |
>>>>>>>>>>> |||
>>>>>>>>>>> ||Thanks||
>>>>>>>>>>> ||- Ioi||
>>>>>>>>>>> ||
>>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>>> |
>>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>>> CHECK_
>>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>>> expect any
>>>>>>>>>>>> exceptions to be possible. I would check with Karen on 
>>>>>>>>>>>> this. ||
>>>>>>>>>>>> |
>>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>>> changes.
>>>>>>>>>> I can give it a try.
>>>>>>>>>> |
>>>>>>>>>>>> || |
>>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>>> |
>>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>>> It won't be needed if the method is declared with TRAPS as 
>>>>>>>>>> the last
>>>>>>>>>> parameter (I think).
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> Calvin
>>>>>>>>>> |
>>>>>>>>>>>> || |
>>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>>>> throwing
>>>>>>>>>>>> exceptions - don't know what the thought process was there 
>>>>>>>>>>>> :) ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||David ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>>> |
>>>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>>> similar
>>>>>>>>>>>>> crash ||
>>>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>>>> the ||
>>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>>> crash if
>>>>>>>>>>>>> the ||
>>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>>> ||} ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> above test ||
>>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>>>> thrown ||
>>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>>> ||         at 
>>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>>> Method) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> |
>>>>>>>>>>> |
>>>>>>>>>>> |
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>


From yumin.qi at oracle.com  Wed Aug 21 13:24:24 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 21 Aug 2013 13:24:24 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52152131.4080204@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
	<52151504.7030408@oracle.com> <52152131.4080204@oracle.com>
Message-ID: <521521F8.60300@oracle.com>

Much much better than the old one.

Thanks
Yumin
On 8/21/2013 1:21 PM, Calvin Cheung wrote:
> I was thinking about updating the bug synopsis.
> How about the following?
> invalid jar file in the bootclasspath can lead to jvm fatal error
>
> Calvin
>
> On 8/21/2013 12:29 PM, Yumin Qi wrote:
>> Not a review, only a suggestion, the bug description should be 
>> modified. Confused.
>>
>> Yumin
>>
>> On 8/21/2013 11:49 AM, Calvin Cheung wrote:
>>> Can someone review this?
>>>
>>> Latest version:
>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>
>>> Previous version without using TRAPS:
>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>>>
>>> thanks,
>>> Calvin
>>>
>>> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>>>> Hi David,
>>>>
>>>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>>>> bit more and found that the error was thrown at a very early stage 
>>>> within the init_globals() called from create_vm(). Below is the 
>>>> call stack:
>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>>> st, ClassPathEntry * * new_entry, bool lazy) Line 508 C++
>>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>>> bytes    C++
>>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) 
>>>> Line 322 + 0x8 bytes C++
>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1362 
>>>> + 0x14 bytes    C++
>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 206 + 0x15 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>>>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID id, 
>>>> int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    C++
>>>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>>>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>>>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>>>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>>>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>>>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
>>>> Line 1904 + 0x9 bytes    C++
>>>>      jvm.dll!Universe::genesis(Thread * __the_thread__) Line 353 + 
>>>> 0x9 bytes    C++
>>>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
>>>> >   jvm.dll!init_globals()  Line 114    C++
>>>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>>>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
>>>> args)  Line 5133 + 0xd bytes    C++
>>>>      java.exe!011013bd()
>>>>      [Frames below may be incorrect and/or missing, no symbols 
>>>> loaded for java.exe]
>>>>      java.exe!01101e2f()
>>>>      java.exe!0110c807()
>>>>      java.exe!0110a5a1()
>>>>      java.exe!0110c845()
>>>>      java.exe!0110a62b()
>>>>      kernel32.dll!767633aa()
>>>>      ntdll.dll!77739ef2()
>>>>      ntdll.dll!77739ec5()
>>>>
>>>> The error was thrown in the method below:
>>>> bool Exceptions::special_exception(Thread* thread, const char* 
>>>> file, int line, Symbol* h_name, const char* message) {
>>>>   // bootstrapping check
>>>>   if (!Universe::is_fully_initialized()) {
>>>>     if (h_name == NULL) {
>>>>       // atleast an informative message.
>>>>       vm_exit_during_initialization("Exception", message);
>>>>     } else {
>>>>       vm_exit_during_initialization(h_name, message);               
>>>> <=====here
>>>>     }
>>>>     ShouldNotReachHere();
>>>>   }
>>>> }
>>>>
>>>> Note that it happened in the early stage during create_vm(), so the 
>>>> (!Universe::is_fully_initialized()) was true.
>>>>
>>>> The class it was trying to load was sun/misc/AtomicLongCSImpl which 
>>>> I couldn't find in 7u25.
>>>> It was going through all the jar files in the bootclasspath and 
>>>> finally got to the foo.jar which has 0-byte and got "error in 
>>>> opening jar file" and then THROW_MSG().
>>>> So I think it's just a coincident in 7u25 where the correct error 
>>>> was thrown.
>>>>
>>>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>>>> and thus it didn't hit the "error in opening jar file" (for the 
>>>> foo.jar) early until it passed the point when the vm is considered 
>>>> "initialized" - is_init_completed() is true. So when THROW_MSG() 
>>>> was called when it tried to load the class specified by the test 
>>>> case ("xxx"), it triggered the fatal error in ~ExceptionMark(). 
>>>> Call stack up to the THROWN_MSG() as follows:
>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>>> st, ClassPathEntry * * new_entry, bool lazy) Line 508 C++
>>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>>> bytes    C++
>>>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  
>>>> Line 322 + 0x8 bytes    C++
>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>> __the_thread__)  Line 900 + 0x17 bytes C++
>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1301 
>>>> + 0x14 bytes    C++
>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char 
>>>> * name)  Line 773 + 0x12 bytes    C++
>>>>      java.dll!69461e8c()
>>>>      [Frames below may be incorrect and/or missing, no symbols 
>>>> loaded for java.dll]
>>>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>>>> elem)  Line 207    C++
>>>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>>>> Line 375 + 0x11 bytes    C++
>>>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * 
>>>> thread)  Line 40 + 0x9 bytes    C++
>>>>
>>>> I'll try using TRAPS all the way through the call chain probably 
>>>> starting from ClassLoader::load_classfile().
>>>>
>>>> thanks,
>>>> Calvin
>>>>
>>>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>>>> Hi Calvin,
>>>>>
>>>>> I don't think this works. As I said previously the expectations of 
>>>>> this code with regard to Java exceptions seems to be that it 
>>>>> doesn't expect them at all. If you are using TRAPS etc then it 
>>>>> should be used all the way through the call chain. What we have 
>>>>> now is this call sequence:
>>>>>
>>>>> void ClassLoader::initialize() {
>>>>>   assert(_package_hash_table == NULL, "should have been 
>>>>> initialized by now.");
>>>>>   EXCEPTION_MARK;
>>>>>   ...
>>>>>   setup_bootstrap_search_path();
>>>>>     -> update_class_path_entry_list(path, false);
>>>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>>>> LazyBootClassLoader, CHECK);
>>>>>
>>>>> So if we return after the call to create_class_path_entry with an 
>>>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>>>
>>>>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>>>>> exception check and a vm_exit_during_initialization, if this 
>>>>> exception can readily occur at runtime. But further analysis of 
>>>>> all this code needs to be undertaken.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>>>> I've updated the webrev with 2 changes:
>>>>>> 1) added the TRAPS as the last parameter to the
>>>>>> create_class_path_entry() method;
>>>>>> 2) added a jtreg test case.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>>
>>>>>> Please take a look again.
>>>>>>
>>>>>> One more response in-lined below...
>>>>>>
>>>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>>>> |I found one version of JDK7 that does not crash:||
>>>>>>> ||
>>>>>>> sc11136754 ~$
>>>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>>>
>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>> Error occurred during initialization of VM
>>>>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>>>>> |
>>>>>>
>>>>>> |I noticed that it started breaking in 7u40 b01; it was still 
>>>>>> working
>>>>>> with 7u25.
>>>>>> It may have something to do with when the set_init_completed() is 
>>>>>> called:
>>>>>> ExceptionMark::~ExceptionMark() {
>>>>>>    if (_thread->has_pending_exception()) {
>>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>>> recursion
>>>>>>      if (is_init_completed()) {
>>>>>>        exception->print();
>>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>>> exceptions");
>>>>>>      } else {
>>>>>>        vm_exit_during_initialization(exception);
>>>>>>      }
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>> Before 7u40, I think the code path got to the "else" branch of
>>>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>>>
>>>>>> set_init_completed() is only called from Threads::create_vm() and 
>>>>>> that
>>>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by 
>>>>>> default?
>>>>>>
>>>>>> Debugging with hs25, the set_init_completed() always happened before
>>>>>> create_class_path_entry() and both calls were done within the same
>>>>>> thread - "vm startup".
>>>>>>
>>>>>> thanks,
>>>>>> Calvin
>>>>>>
>>>>>>
>>>>>> |
>>>>>>> |||
>>>>>>> ||
>>>>>>> ||- Ioi
>>>>>>> |
>>>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>>>> |I found an official version that's closest to the Redhat version
>>>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>>>> crashes.||
>>>>>>>> ||
>>>>>>>> ||sc11136754 ~$
>>>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java 
>>>>>>>> -showversion
>>>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>> ||java version "1.6.0_25"||
>>>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>> ||
>>>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>>>> ||#||
>>>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>>>> Environment:||
>>>>>>>> ||#||
>>>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>>>> tid=140608485558016||
>>>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>>>> exceptions||
>>>>>>>> ||#||
>>>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed 
>>>>>>>> mode
>>>>>>>> linux-amd64 compressed oops)||
>>>>>>>> ||# An error report file with more information is saved as:||
>>>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>>>> ||#||
>>>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>>>> ||#||
>>>>>>>> ||Aborted (core dumped)||
>>>>>>>> |
>>>>>>>> - Ioi
>>>>>>>>
>>>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>>>> apparently
>>>>>>>>>> works differently
>>>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed 
>>>>>>>>>> this in
>>>>>>>>>> their
>>>>>>>>>> own repo??||
>>>>>>>>>
>>>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> ||
>>>>>>>>>> |
>>>>>>>>>> |==OEL6================================================
>>>>>>>>>> ||
>>>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>>>> ||sc11136754 ~$ java -showversion -cp . 
>>>>>>>>>> -Xbootclasspath/a:foo.jar
>>>>>>>>>> test2||
>>>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>>>> foo.jar||
>>>>>>>>>> ||
>>>>>>>>>> ==OFFICIAL============================================
>>>>>>>>>> ||
>>>>>>>>>> sc11136754 ~$ 
>>>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>>>> java version "1.6.0_22"
>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>>>
>>>>>>>>>> #
>>>>>>>>>> # A fatal error has been detected by the Java Runtime 
>>>>>>>>>> Environment:
>>>>>>>>>> #
>>>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>>>> tid=140510319580928
>>>>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>>>>> #
>>>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed 
>>>>>>>>>> mode
>>>>>>>>>> linux-amd64 )
>>>>>>>>>> # An error report file with more information is saved as:
>>>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>>>> #
>>>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>>>> #
>>>>>>>>>> |
>>>>>>>>>> |======================================================
>>>>>>>>>> ||
>>>>>>>>>> ||- Ioi|
>>>>>>>>>>
>>>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>>>> Hi Ioi, David,
>>>>>>>>>>>
>>>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>>>> files in
>>>>>>>>>>>> the JDK:||
>>>>>>>>>>>> ||
>>>>>>>>>>>> ||=========================||
>>>>>>>>>>>> ||/*||
>>>>>>>>>>>> ||javac test2.java||
>>>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>>> ||*/||
>>>>>>>>>>>> ||
>>>>>>>>>>>> ||public class test2 {||
>>>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>>>> ||        try {||
>>>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>>>> ||        }||
>>>>>>>>>>>> ||    }||
>>>>>>>>>>>> ||}||
>>>>>>>>>>>> ||=========================||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second 
>>>>>>>>>>>> "java -cp .
>>>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>>>> |
>>>>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>>>>> cases.
>>>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>>>> |
>>>>>>>>>>>> |||
>>>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 
>>>>>>>>>>>> behavior (not
>>>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>>>> checking),
>>>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>>>> |
>>>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I 
>>>>>>>>>>> changed look
>>>>>>>>>>> the
>>>>>>>>>>> same as jdk 8.
>>>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>>>> |
>>>>>>>>>>>> |||
>>>>>>>>>>>> ||Thanks||
>>>>>>>>>>>> ||- Ioi||
>>>>>>>>>>>> ||
>>>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>>>> |
>>>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>>>> exceptions. If exceptions can be posted then methods 
>>>>>>>>>>>>> should be
>>>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>>>> CHECK_
>>>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>>>> expect any
>>>>>>>>>>>>> exceptions to be possible. I would check with Karen on 
>>>>>>>>>>>>> this. ||
>>>>>>>>>>>>> |
>>>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>>>> changes.
>>>>>>>>>>> I can give it a try.
>>>>>>>>>>> |
>>>>>>>>>>>>> || |
>>>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>>>> |
>>>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>>>> It won't be needed if the method is declared with TRAPS as 
>>>>>>>>>>> the last
>>>>>>>>>>> parameter (I think).
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>> Calvin
>>>>>>>>>>> |
>>>>>>>>>>>>> || |
>>>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>>>>> throwing
>>>>>>>>>>>>> exceptions - don't know what the thought process was there 
>>>>>>>>>>>>> :) ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||David ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>>>> |
>>>>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>>>> similar
>>>>>>>>>>>>>> crash ||
>>>>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>>>>> the ||
>>>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>>>> crash if
>>>>>>>>>>>>>> the ||
>>>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>>>> ||} ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail 
>>>>>>>>>>>>>> under the
>>>>>>>>>>>>>> above test ||
>>>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>>>>> thrown ||
>>>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>>>> ||         at 
>>>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>>>> Method) ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) || 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>>>> ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> |
>>>>>>>>>>>> |
>>>>>>>>>>>> |
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Wed Aug 21 13:48:27 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 21 Aug 2013 16:48:27 -0400
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52150BD6.2090408@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
Message-ID: <5215279B.50307@oracle.com>


Hi Calvin,

Why doesn't resolve_entry() also have TRAPS argument?  There are calls 
that expect it not to return null still in the code?   And then 
LazyClassPathEntry::open_stream needs TRAPS too, and then I think you 
are done because the caller already has TRAPS.

Coleen

On 8/21/2013 2:49 PM, Calvin Cheung wrote:
> Can someone review this?
>
> Latest version:
> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>
> Previous version without using TRAPS:
> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>
> thanks,
> Calvin
>
> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>> Hi David,
>>
>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>> bit more and found that the error was thrown at a very early stage 
>> within the init_globals() called from create_vm(). Below is the call 
>> stack:
>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>> bytes    C++
>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) Line 
>> 322 + 0x8 bytes C++
>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>> class_name, Handle class_loader, Thread * __the_thread__)  Line 1362 
>> + 0x14 bytes    C++
>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>> name, Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 206 + 0x15 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
>> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    C++
>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
>> Line 1904 + 0x9 bytes    C++
>>      jvm.dll!Universe::genesis(Thread * __the_thread__)  Line 353 + 
>> 0x9 bytes    C++
>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
>> >   jvm.dll!init_globals()  Line 114    C++
>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
>> args)  Line 5133 + 0xd bytes    C++
>>      java.exe!011013bd()
>>      [Frames below may be incorrect and/or missing, no symbols loaded 
>> for java.exe]
>>      java.exe!01101e2f()
>>      java.exe!0110c807()
>>      java.exe!0110a5a1()
>>      java.exe!0110c845()
>>      java.exe!0110a62b()
>>      kernel32.dll!767633aa()
>>      ntdll.dll!77739ef2()
>>      ntdll.dll!77739ec5()
>>
>> The error was thrown in the method below:
>> bool Exceptions::special_exception(Thread* thread, const char* file, 
>> int line, Symbol* h_name, const char* message) {
>>   // bootstrapping check
>>   if (!Universe::is_fully_initialized()) {
>>     if (h_name == NULL) {
>>       // atleast an informative message.
>>       vm_exit_during_initialization("Exception", message);
>>     } else {
>>       vm_exit_during_initialization(h_name, message);               
>> <=====here
>>     }
>>     ShouldNotReachHere();
>>   }
>> }
>>
>> Note that it happened in the early stage during create_vm(), so the 
>> (!Universe::is_fully_initialized()) was true.
>>
>> The class it was trying to load was sun/misc/AtomicLongCSImpl which I 
>> couldn't find in 7u25.
>> It was going through all the jar files in the bootclasspath and 
>> finally got to the foo.jar which has 0-byte and got "error in opening 
>> jar file" and then THROW_MSG().
>> So I think it's just a coincident in 7u25 where the correct error was 
>> thrown.
>>
>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>> and thus it didn't hit the "error in opening jar file" (for the 
>> foo.jar) early until it passed the point when the vm is considered 
>> "initialized" - is_init_completed() is true. So when THROW_MSG() was 
>> called when it tried to load the class specified by the test case 
>> ("xxx"), it triggered the fatal error in ~ExceptionMark(). Call stack 
>> up to the THROWN_MSG() as follows:
>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>> bytes    C++
>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  Line 
>> 322 + 0x8 bytes    C++
>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>> __the_thread__)  Line 900 + 0x17 bytes C++
>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>> class_name, Handle class_loader, Thread * __the_thread__)  Line 1301 
>> + 0x14 bytes    C++
>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>> name, Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>> name)  Line 773 + 0x12 bytes    C++
>>      java.dll!69461e8c()
>>      [Frames below may be incorrect and/or missing, no symbols loaded 
>> for java.dll]
>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>> elem)  Line 207    C++
>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>> Line 375 + 0x11 bytes    C++
>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * thread)  
>> Line 40 + 0x9 bytes    C++
>>
>> I'll try using TRAPS all the way through the call chain probably 
>> starting from ClassLoader::load_classfile().
>>
>> thanks,
>> Calvin
>>
>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>> Hi Calvin,
>>>
>>> I don't think this works. As I said previously the expectations of 
>>> this code with regard to Java exceptions seems to be that it doesn't 
>>> expect them at all. If you are using TRAPS etc then it should be 
>>> used all the way through the call chain. What we have now is this 
>>> call sequence:
>>>
>>> void ClassLoader::initialize() {
>>>   assert(_package_hash_table == NULL, "should have been initialized 
>>> by now.");
>>>   EXCEPTION_MARK;
>>>   ...
>>>   setup_bootstrap_search_path();
>>>     -> update_class_path_entry_list(path, false);
>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>> LazyBootClassLoader, CHECK);
>>>
>>> So if we return after the call to create_class_path_entry with an 
>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>
>>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>>> exception check and a vm_exit_during_initialization, if this 
>>> exception can readily occur at runtime. But further analysis of all 
>>> this code needs to be undertaken.
>>>
>>> David
>>> -----
>>>
>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>> I've updated the webrev with 2 changes:
>>>> 1) added the TRAPS as the last parameter to the
>>>> create_class_path_entry() method;
>>>> 2) added a jtreg test case.
>>>>
>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>
>>>> Please take a look again.
>>>>
>>>> One more response in-lined below...
>>>>
>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>> |I found one version of JDK7 that does not crash:||
>>>>> ||
>>>>> sc11136754 ~$
>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>
>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>> Error occurred during initialization of VM
>>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>>> |
>>>>
>>>> |I noticed that it started breaking in 7u40 b01; it was still working
>>>> with 7u25.
>>>> It may have something to do with when the set_init_completed() is 
>>>> called:
>>>> ExceptionMark::~ExceptionMark() {
>>>>    if (_thread->has_pending_exception()) {
>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>> recursion
>>>>      if (is_init_completed()) {
>>>>        exception->print();
>>>>        fatal("ExceptionMark destructor expects no pending 
>>>> exceptions");
>>>>      } else {
>>>>        vm_exit_during_initialization(exception);
>>>>      }
>>>>    }
>>>> }
>>>>
>>>> Before 7u40, I think the code path got to the "else" branch of
>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>
>>>> set_init_completed() is only called from Threads::create_vm() and that
>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>>>>
>>>> Debugging with hs25, the set_init_completed() always happened before
>>>> create_class_path_entry() and both calls were done within the same
>>>> thread - "vm startup".
>>>>
>>>> thanks,
>>>> Calvin
>>>>
>>>>
>>>> |
>>>>> |||
>>>>> ||
>>>>> ||- Ioi
>>>>> |
>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>> |I found an official version that's closest to the Redhat version
>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>> crashes.||
>>>>>> ||
>>>>>> ||sc11136754 ~$
>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>> ||java version "1.6.0_25"||
>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>> ||
>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>> ||#||
>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>> Environment:||
>>>>>> ||#||
>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>> tid=140608485558016||
>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>> exceptions||
>>>>>> ||#||
>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>>>>> linux-amd64 compressed oops)||
>>>>>> ||# An error report file with more information is saved as:||
>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>> ||#||
>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>> ||#||
>>>>>> ||Aborted (core dumped)||
>>>>>> |
>>>>>> - Ioi
>>>>>>
>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>> apparently
>>>>>>>> works differently
>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed this in
>>>>>>>> their
>>>>>>>> own repo??||
>>>>>>>
>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> ||
>>>>>>>> |
>>>>>>>> |==OEL6================================================
>>>>>>>> ||
>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>>>>> test2||
>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>> foo.jar||
>>>>>>>> ||
>>>>>>>> ==OFFICIAL============================================
>>>>>>>> ||
>>>>>>>> sc11136754 ~$ 
>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>> java version "1.6.0_22"
>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>
>>>>>>>> #
>>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>>> #
>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>> tid=140510319580928
>>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>>> #
>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>>>>> linux-amd64 )
>>>>>>>> # An error report file with more information is saved as:
>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>> #
>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>> #
>>>>>>>> |
>>>>>>>> |======================================================
>>>>>>>> ||
>>>>>>>> ||- Ioi|
>>>>>>>>
>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>> Hi Ioi, David,
>>>>>>>>>
>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>> files in
>>>>>>>>>> the JDK:||
>>>>>>>>>> ||
>>>>>>>>>> ||=========================||
>>>>>>>>>> ||/*||
>>>>>>>>>> ||javac test2.java||
>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>> ||*/||
>>>>>>>>>> ||
>>>>>>>>>> ||public class test2 {||
>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>> ||        try {||
>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>> ||        }||
>>>>>>>>>> ||    }||
>>>>>>>>>> ||}||
>>>>>>>>>> ||=========================||
>>>>>>>>>> | |
>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second "java 
>>>>>>>>>> -cp .
>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>> |
>>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>>> cases.
>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>> |
>>>>>>>>>> |||
>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior 
>>>>>>>>>> (not
>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>> checking),
>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>> |
>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I changed 
>>>>>>>>> look
>>>>>>>>> the
>>>>>>>>> same as jdk 8.
>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>> |
>>>>>>>>>> |||
>>>>>>>>>> ||Thanks||
>>>>>>>>>> ||- Ioi||
>>>>>>>>>> ||
>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>> |
>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>> CHECK_
>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>> expect any
>>>>>>>>>>> exceptions to be possible. I would check with Karen on this. ||
>>>>>>>>>>> |
>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>> changes.
>>>>>>>>> I can give it a try.
>>>>>>>>> |
>>>>>>>>>>> || |
>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>> |
>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>> It won't be needed if the method is declared with TRAPS as the 
>>>>>>>>> last
>>>>>>>>> parameter (I think).
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> Calvin
>>>>>>>>> |
>>>>>>>>>>> || |
>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>>> throwing
>>>>>>>>>>> exceptions - don't know what the thought process was there 
>>>>>>>>>>> :) ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||David ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>> |
>>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>> similar
>>>>>>>>>>>> crash ||
>>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>>> the ||
>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>> crash if
>>>>>>>>>>>> the ||
>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>> ||} ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>>>>>>>>> above test ||
>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>>> thrown ||
>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>> ||         at 
>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>> Method) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>> ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> | |
>>>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>


From ioi.lam at oracle.com  Wed Aug 21 14:01:50 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 21 Aug 2013 14:01:50 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52150BD6.2090408@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
Message-ID: <52152ABE.5000804@oracle.com>

Calvin,

I have not looked at the code in detail, but will your code now 
repeatedly attempt to open the invalid JAR file? Maybe you can test that 
by adding multiple Class.forName() calls in your tests (and catching any 
exceptions).

This is an error case (having an invalid JAR file in bootclasspath) so 
performance is not important. However, if there's a simple way to 
remember the result and never open the JAR file again that would be ideal.

Thanks
- Ioi

On 08/21/2013 11:49 AM, Calvin Cheung wrote:
> Can someone review this?
>
> Latest version:
> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>
> Previous version without using TRAPS:
> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>
> thanks,
> Calvin
>
> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>> Hi David,
>>
>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>> bit more and found that the error was thrown at a very early stage 
>> within the init_globals() called from create_vm(). Below is the call 
>> stack:
>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>> bytes    C++
>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) Line 
>> 322 + 0x8 bytes C++
>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>> class_name, Handle class_loader, Thread * __the_thread__)  Line 1362 
>> + 0x14 bytes    C++
>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>> name, Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 206 + 0x15 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
>> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    C++
>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
>> Line 1904 + 0x9 bytes    C++
>>      jvm.dll!Universe::genesis(Thread * __the_thread__)  Line 353 + 
>> 0x9 bytes    C++
>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
>> >   jvm.dll!init_globals()  Line 114    C++
>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
>> args)  Line 5133 + 0xd bytes    C++
>>      java.exe!011013bd()
>>      [Frames below may be incorrect and/or missing, no symbols loaded 
>> for java.exe]
>>      java.exe!01101e2f()
>>      java.exe!0110c807()
>>      java.exe!0110a5a1()
>>      java.exe!0110c845()
>>      java.exe!0110a62b()
>>      kernel32.dll!767633aa()
>>      ntdll.dll!77739ef2()
>>      ntdll.dll!77739ec5()
>>
>> The error was thrown in the method below:
>> bool Exceptions::special_exception(Thread* thread, const char* file, 
>> int line, Symbol* h_name, const char* message) {
>>   // bootstrapping check
>>   if (!Universe::is_fully_initialized()) {
>>     if (h_name == NULL) {
>>       // atleast an informative message.
>>       vm_exit_during_initialization("Exception", message);
>>     } else {
>>       vm_exit_during_initialization(h_name, message);               
>> <=====here
>>     }
>>     ShouldNotReachHere();
>>   }
>> }
>>
>> Note that it happened in the early stage during create_vm(), so the 
>> (!Universe::is_fully_initialized()) was true.
>>
>> The class it was trying to load was sun/misc/AtomicLongCSImpl which I 
>> couldn't find in 7u25.
>> It was going through all the jar files in the bootclasspath and 
>> finally got to the foo.jar which has 0-byte and got "error in opening 
>> jar file" and then THROW_MSG().
>> So I think it's just a coincident in 7u25 where the correct error was 
>> thrown.
>>
>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>> and thus it didn't hit the "error in opening jar file" (for the 
>> foo.jar) early until it passed the point when the vm is considered 
>> "initialized" - is_init_completed() is true. So when THROW_MSG() was 
>> called when it tried to load the class specified by the test case 
>> ("xxx"), it triggered the fatal error in ~ExceptionMark(). Call stack 
>> up to the THROWN_MSG() as follows:
>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>> bytes    C++
>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  Line 
>> 322 + 0x8 bytes    C++
>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>> __the_thread__)  Line 900 + 0x17 bytes C++
>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>> class_name, Handle class_loader, Thread * __the_thread__)  Line 1301 
>> + 0x14 bytes    C++
>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>> name, Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>> name)  Line 773 + 0x12 bytes    C++
>>      java.dll!69461e8c()
>>      [Frames below may be incorrect and/or missing, no symbols loaded 
>> for java.dll]
>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>> elem)  Line 207    C++
>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>> Line 375 + 0x11 bytes    C++
>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * thread)  
>> Line 40 + 0x9 bytes    C++
>>
>> I'll try using TRAPS all the way through the call chain probably 
>> starting from ClassLoader::load_classfile().
>>
>> thanks,
>> Calvin
>>
>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>> Hi Calvin,
>>>
>>> I don't think this works. As I said previously the expectations of 
>>> this code with regard to Java exceptions seems to be that it doesn't 
>>> expect them at all. If you are using TRAPS etc then it should be 
>>> used all the way through the call chain. What we have now is this 
>>> call sequence:
>>>
>>> void ClassLoader::initialize() {
>>>   assert(_package_hash_table == NULL, "should have been initialized 
>>> by now.");
>>>   EXCEPTION_MARK;
>>>   ...
>>>   setup_bootstrap_search_path();
>>>     -> update_class_path_entry_list(path, false);
>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>> LazyBootClassLoader, CHECK);
>>>
>>> So if we return after the call to create_class_path_entry with an 
>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>
>>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>>> exception check and a vm_exit_during_initialization, if this 
>>> exception can readily occur at runtime. But further analysis of all 
>>> this code needs to be undertaken.
>>>
>>> David
>>> -----
>>>
>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>> I've updated the webrev with 2 changes:
>>>> 1) added the TRAPS as the last parameter to the
>>>> create_class_path_entry() method;
>>>> 2) added a jtreg test case.
>>>>
>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>
>>>> Please take a look again.
>>>>
>>>> One more response in-lined below...
>>>>
>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>> |I found one version of JDK7 that does not crash:||
>>>>> ||
>>>>> sc11136754 ~$
>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>
>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>> Error occurred during initialization of VM
>>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>>> |
>>>>
>>>> |I noticed that it started breaking in 7u40 b01; it was still working
>>>> with 7u25.
>>>> It may have something to do with when the set_init_completed() is 
>>>> called:
>>>> ExceptionMark::~ExceptionMark() {
>>>>    if (_thread->has_pending_exception()) {
>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>> recursion
>>>>      if (is_init_completed()) {
>>>>        exception->print();
>>>>        fatal("ExceptionMark destructor expects no pending 
>>>> exceptions");
>>>>      } else {
>>>>        vm_exit_during_initialization(exception);
>>>>      }
>>>>    }
>>>> }
>>>>
>>>> Before 7u40, I think the code path got to the "else" branch of
>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>
>>>> set_init_completed() is only called from Threads::create_vm() and that
>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>>>>
>>>> Debugging with hs25, the set_init_completed() always happened before
>>>> create_class_path_entry() and both calls were done within the same
>>>> thread - "vm startup".
>>>>
>>>> thanks,
>>>> Calvin
>>>>
>>>>
>>>> |
>>>>> |||
>>>>> ||
>>>>> ||- Ioi
>>>>> |
>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>> |I found an official version that's closest to the Redhat version
>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>> crashes.||
>>>>>> ||
>>>>>> ||sc11136754 ~$
>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>> ||java version "1.6.0_25"||
>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>> ||
>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>> ||#||
>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>> Environment:||
>>>>>> ||#||
>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>> tid=140608485558016||
>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>> exceptions||
>>>>>> ||#||
>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>>>>> linux-amd64 compressed oops)||
>>>>>> ||# An error report file with more information is saved as:||
>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>> ||#||
>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>> ||#||
>>>>>> ||Aborted (core dumped)||
>>>>>> |
>>>>>> - Ioi
>>>>>>
>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>> apparently
>>>>>>>> works differently
>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed this in
>>>>>>>> their
>>>>>>>> own repo??||
>>>>>>>
>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> ||
>>>>>>>> |
>>>>>>>> |==OEL6================================================
>>>>>>>> ||
>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>>>>> test2||
>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>> foo.jar||
>>>>>>>> ||
>>>>>>>> ==OFFICIAL============================================
>>>>>>>> ||
>>>>>>>> sc11136754 ~$ 
>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>> java version "1.6.0_22"
>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>
>>>>>>>> #
>>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>>> #
>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>> tid=140510319580928
>>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>>> #
>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>>>>> linux-amd64 )
>>>>>>>> # An error report file with more information is saved as:
>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>> #
>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>> #
>>>>>>>> |
>>>>>>>> |======================================================
>>>>>>>> ||
>>>>>>>> ||- Ioi|
>>>>>>>>
>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>> Hi Ioi, David,
>>>>>>>>>
>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>> files in
>>>>>>>>>> the JDK:||
>>>>>>>>>> ||
>>>>>>>>>> ||=========================||
>>>>>>>>>> ||/*||
>>>>>>>>>> ||javac test2.java||
>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>> ||*/||
>>>>>>>>>> ||
>>>>>>>>>> ||public class test2 {||
>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>> ||        try {||
>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>> ||        }||
>>>>>>>>>> ||    }||
>>>>>>>>>> ||}||
>>>>>>>>>> ||=========================||
>>>>>>>>>> | |
>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second "java 
>>>>>>>>>> -cp .
>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>> |
>>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>>> cases.
>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>> |
>>>>>>>>>> |||
>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior 
>>>>>>>>>> (not
>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>> checking),
>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>> |
>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I changed 
>>>>>>>>> look
>>>>>>>>> the
>>>>>>>>> same as jdk 8.
>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>> |
>>>>>>>>>> |||
>>>>>>>>>> ||Thanks||
>>>>>>>>>> ||- Ioi||
>>>>>>>>>> ||
>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>> |
>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>> CHECK_
>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>> expect any
>>>>>>>>>>> exceptions to be possible. I would check with Karen on this. ||
>>>>>>>>>>> |
>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>> changes.
>>>>>>>>> I can give it a try.
>>>>>>>>> |
>>>>>>>>>>> || |
>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>> |
>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>> It won't be needed if the method is declared with TRAPS as the 
>>>>>>>>> last
>>>>>>>>> parameter (I think).
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> Calvin
>>>>>>>>> |
>>>>>>>>>>> || |
>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>>> throwing
>>>>>>>>>>> exceptions - don't know what the thought process was there 
>>>>>>>>>>> :) ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||David ||
>>>>>>>>>>> | |
>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>> |
>>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>> similar
>>>>>>>>>>>> crash ||
>>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>>> the ||
>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>> crash if
>>>>>>>>>>>> the ||
>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>> ||} ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under the
>>>>>>>>>>>> above test ||
>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>>> thrown ||
>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>> ||         at 
>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>> Method) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>> ||
>>>>>>>>>>>> ||         at
>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> | |
>>>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>


From harold.seigel at oracle.com  Wed Aug 21 14:19:31 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 21 Aug 2013 17:19:31 -0400
Subject: RFR 8022183: GCC 4.56 changes default setting for omit-frame-pointer
	which breaks hotspot stack walking
Message-ID: <52152EE3.2040804@oracle.com>

Hi,

Please review this small fix for bug 8022183.  This fix is needed in 
order to build hotspot on 32-bit Linux with newer versions of gcc. The 
fix explicitly specifies "-fno-omit-frame-pointer" in the makefile for 
32-bit Linux.

The fix was tested using NMT with -version and with GCBasher.

Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>

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

JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183

Thanks, Harold

From daniel.daugherty at oracle.com  Wed Aug 21 15:27:25 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 21 Aug 2013 16:27:25 -0600
Subject: RFR 8022183: GCC 4.56 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <52152EE3.2040804@oracle.com>
References: <52152EE3.2040804@oracle.com>
Message-ID: <52153ECD.9030006@oracle.com>

On 8/21/13 3:19 PM, harold seigel wrote:
> Hi,
>
> Please review this small fix for bug 8022183.  This fix is needed in 
> order to build hotspot on 32-bit Linux with newer versions of gcc. The 
> fix explicitly specifies "-fno-omit-frame-pointer" in the makefile for 
> 32-bit Linux.
>
> The fix was tested using NMT with -version and with GCBasher.
>
> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>

make/linux/makefiles/i486.make
     No comments.

Thumbs up!

Dan


>
> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>
> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>
> Thanks, Harold


From yumin.qi at oracle.com  Wed Aug 21 15:43:47 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 21 Aug 2013 15:43:47 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <520CF52B.6050000@oracle.com>
References: <520CF52B.6050000@oracle.com>
Message-ID: <521542A3.3020906@oracle.com>

Hi, all

   This is second version after feedback from first round.
   The changes are:

   1) file name will be based on gc log file name (-Xloggc:filename), 
pid (process id) and time when the first rotation file created:
        <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
   2) If rotate in same file, file name is as in 1), if rotate in 
multiple files, .<i> will append to above file name.
   3) every time file rotated, file name and time when file created will 
be logged to head/tail, this is same as first version.
   4) current file has name 
<filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
        This is similar to first version.
        By adapting such name format we will never loss logs in case 
apps stops and restart, the log files will not be overwritten since time 
stamp in file names.
    5) If open file failed, turn off gc log rotation.
         If due to some reason, file operation failed (such as 
permission changed etc), with log file opened, logging still works, but at
         saving and renaming, the file operation will fail, this will 
lead not all files saved.

http://cr.openjdk.java.net/~minqi/7164841/webrev01

      Tested with jtreg, JPRT.

Thanks
Yumin

On 8/15/2013 8:35 AM, Yumin Qi wrote:
> Hi,
>
>   Can I have your review for this small changes?
> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>
>    This is for a enhancement to add head/tail message to the logging 
> files to assist reading GC output.
>    1. modified prompt message if invalid arguments used for log rotating;
>    2. add time and file name message to log file head/tail.
>    3. for easily identify which log file is current, use file name 
> like <filename>.n.current, after it reaches maximum size, rename it to 
> <filename>.n
>         On Windows, there is no F_OK (existing test) definition, F_OK 
> is defined as "0" and for _access of VC++, it just describes:
>
> modevalue
>
> 	
>
> Checks file for
>
> 00
>
> 	
>
> Existence only
>
> 02
>
> 	
>
> Write-only
>
> 04
>
> 	
>
> Read-only
>
> 06
>
> 	
>
> Read and write
>
>
> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
> The definition are consistent with unistd.h.
>
>     Test: JPRT and jtreg.
>
>    Thanks
>    Yumin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130821/512391b5/attachment-0001.html 

From calvin.cheung at oracle.com  Wed Aug 21 15:55:15 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Wed, 21 Aug 2013 15:55:15 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <5215279B.50307@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
	<5215279B.50307@oracle.com>
Message-ID: <52154553.80602@oracle.com>

Hi Coleen,

Thanks for your review.
I don't recall any reasons other then keeping the fix small.
I've added TRAPS to those methods and it seems to be building fine.
I'll send an updated webrev after more testing.

Calvin

On 8/21/2013 1:48 PM, Coleen Phillimore wrote:
>
> Hi Calvin,
>
> Why doesn't resolve_entry() also have TRAPS argument?  There are calls 
> that expect it not to return null still in the code?   And then 
> LazyClassPathEntry::open_stream needs TRAPS too, and then I think you 
> are done because the caller already has TRAPS.
>
> Coleen
>
> On 8/21/2013 2:49 PM, Calvin Cheung wrote:
>> Can someone review this?
>>
>> Latest version:
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>
>> Previous version without using TRAPS:
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>>
>> thanks,
>> Calvin
>>
>> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>>> Hi David,
>>>
>>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>>> bit more and found that the error was thrown at a very early stage 
>>> within the init_globals() called from create_vm(). Below is the call 
>>> stack:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>> bytes    C++
>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) Line 
>>> 322 + 0x8 bytes C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1362 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 206 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
>>> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    
>>> C++
>>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
>>> Line 1904 + 0x9 bytes    C++
>>>      jvm.dll!Universe::genesis(Thread * __the_thread__)  Line 353 + 
>>> 0x9 bytes    C++
>>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
>>> >   jvm.dll!init_globals()  Line 114    C++
>>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
>>> args)  Line 5133 + 0xd bytes    C++
>>>      java.exe!011013bd()
>>>      [Frames below may be incorrect and/or missing, no symbols 
>>> loaded for java.exe]
>>>      java.exe!01101e2f()
>>>      java.exe!0110c807()
>>>      java.exe!0110a5a1()
>>>      java.exe!0110c845()
>>>      java.exe!0110a62b()
>>>      kernel32.dll!767633aa()
>>>      ntdll.dll!77739ef2()
>>>      ntdll.dll!77739ec5()
>>>
>>> The error was thrown in the method below:
>>> bool Exceptions::special_exception(Thread* thread, const char* file, 
>>> int line, Symbol* h_name, const char* message) {
>>>   // bootstrapping check
>>>   if (!Universe::is_fully_initialized()) {
>>>     if (h_name == NULL) {
>>>       // atleast an informative message.
>>>       vm_exit_during_initialization("Exception", message);
>>>     } else {
>>>       vm_exit_during_initialization(h_name, message);               
>>> <=====here
>>>     }
>>>     ShouldNotReachHere();
>>>   }
>>> }
>>>
>>> Note that it happened in the early stage during create_vm(), so the 
>>> (!Universe::is_fully_initialized()) was true.
>>>
>>> The class it was trying to load was sun/misc/AtomicLongCSImpl which 
>>> I couldn't find in 7u25.
>>> It was going through all the jar files in the bootclasspath and 
>>> finally got to the foo.jar which has 0-byte and got "error in 
>>> opening jar file" and then THROW_MSG().
>>> So I think it's just a coincident in 7u25 where the correct error 
>>> was thrown.
>>>
>>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>>> and thus it didn't hit the "error in opening jar file" (for the 
>>> foo.jar) early until it passed the point when the vm is considered 
>>> "initialized" - is_init_completed() is true. So when THROW_MSG() was 
>>> called when it tried to load the class specified by the test case 
>>> ("xxx"), it triggered the fatal error in ~ExceptionMark(). Call 
>>> stack up to the THROWN_MSG() as follows:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>> bytes    C++
>>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  
>>> Line 322 + 0x8 bytes    C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 900 + 0x17 bytes C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1301 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>>> name)  Line 773 + 0x12 bytes    C++
>>>      java.dll!69461e8c()
>>>      [Frames below may be incorrect and/or missing, no symbols 
>>> loaded for java.dll]
>>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>>> elem)  Line 207    C++
>>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>>> Line 375 + 0x11 bytes    C++
>>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * 
>>> thread)  Line 40 + 0x9 bytes    C++
>>>
>>> I'll try using TRAPS all the way through the call chain probably 
>>> starting from ClassLoader::load_classfile().
>>>
>>> thanks,
>>> Calvin
>>>
>>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>>> Hi Calvin,
>>>>
>>>> I don't think this works. As I said previously the expectations of 
>>>> this code with regard to Java exceptions seems to be that it 
>>>> doesn't expect them at all. If you are using TRAPS etc then it 
>>>> should be used all the way through the call chain. What we have now 
>>>> is this call sequence:
>>>>
>>>> void ClassLoader::initialize() {
>>>>   assert(_package_hash_table == NULL, "should have been initialized 
>>>> by now.");
>>>>   EXCEPTION_MARK;
>>>>   ...
>>>>   setup_bootstrap_search_path();
>>>>     -> update_class_path_entry_list(path, false);
>>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>>> LazyBootClassLoader, CHECK);
>>>>
>>>> So if we return after the call to create_class_path_entry with an 
>>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>>
>>>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>>>> exception check and a vm_exit_during_initialization, if this 
>>>> exception can readily occur at runtime. But further analysis of all 
>>>> this code needs to be undertaken.
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>>> I've updated the webrev with 2 changes:
>>>>> 1) added the TRAPS as the last parameter to the
>>>>> create_class_path_entry() method;
>>>>> 2) added a jtreg test case.
>>>>>
>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>
>>>>> Please take a look again.
>>>>>
>>>>> One more response in-lined below...
>>>>>
>>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>>> |I found one version of JDK7 that does not crash:||
>>>>>> ||
>>>>>> sc11136754 ~$
>>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>>
>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>> Error occurred during initialization of VM
>>>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>>>> |
>>>>>
>>>>> |I noticed that it started breaking in 7u40 b01; it was still working
>>>>> with 7u25.
>>>>> It may have something to do with when the set_init_completed() is 
>>>>> called:
>>>>> ExceptionMark::~ExceptionMark() {
>>>>>    if (_thread->has_pending_exception()) {
>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>> recursion
>>>>>      if (is_init_completed()) {
>>>>>        exception->print();
>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>> exceptions");
>>>>>      } else {
>>>>>        vm_exit_during_initialization(exception);
>>>>>      }
>>>>>    }
>>>>> }
>>>>>
>>>>> Before 7u40, I think the code path got to the "else" branch of
>>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>>
>>>>> set_init_completed() is only called from Threads::create_vm() and 
>>>>> that
>>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>>>>>
>>>>> Debugging with hs25, the set_init_completed() always happened before
>>>>> create_class_path_entry() and both calls were done within the same
>>>>> thread - "vm startup".
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>>
>>>>> |
>>>>>> |||
>>>>>> ||
>>>>>> ||- Ioi
>>>>>> |
>>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>>> |I found an official version that's closest to the Redhat version
>>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>>> crashes.||
>>>>>>> ||
>>>>>>> ||sc11136754 ~$
>>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>> ||java version "1.6.0_25"||
>>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>> ||
>>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>>> ||#||
>>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>>> Environment:||
>>>>>>> ||#||
>>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>>> tid=140608485558016||
>>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>>> exceptions||
>>>>>>> ||#||
>>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>>>>>> linux-amd64 compressed oops)||
>>>>>>> ||# An error report file with more information is saved as:||
>>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>>> ||#||
>>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>>> ||#||
>>>>>>> ||Aborted (core dumped)||
>>>>>>> |
>>>>>>> - Ioi
>>>>>>>
>>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>>> apparently
>>>>>>>>> works differently
>>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed 
>>>>>>>>> this in
>>>>>>>>> their
>>>>>>>>> own repo??||
>>>>>>>>
>>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> ||
>>>>>>>>> |
>>>>>>>>> |==OEL6================================================
>>>>>>>>> ||
>>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>>>>>> test2||
>>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>>> foo.jar||
>>>>>>>>> ||
>>>>>>>>> ==OFFICIAL============================================
>>>>>>>>> ||
>>>>>>>>> sc11136754 ~$ 
>>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>>> java version "1.6.0_22"
>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>>
>>>>>>>>> #
>>>>>>>>> # A fatal error has been detected by the Java Runtime 
>>>>>>>>> Environment:
>>>>>>>>> #
>>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>>> tid=140510319580928
>>>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>>>> #
>>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>>>>>> linux-amd64 )
>>>>>>>>> # An error report file with more information is saved as:
>>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>>> #
>>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>>> #
>>>>>>>>> |
>>>>>>>>> |======================================================
>>>>>>>>> ||
>>>>>>>>> ||- Ioi|
>>>>>>>>>
>>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>>> Hi Ioi, David,
>>>>>>>>>>
>>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>>> files in
>>>>>>>>>>> the JDK:||
>>>>>>>>>>> ||
>>>>>>>>>>> ||=========================||
>>>>>>>>>>> ||/*||
>>>>>>>>>>> ||javac test2.java||
>>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>> ||*/||
>>>>>>>>>>> ||
>>>>>>>>>>> ||public class test2 {||
>>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>>> ||        try {||
>>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>>> ||        }||
>>>>>>>>>>> ||    }||
>>>>>>>>>>> ||}||
>>>>>>>>>>> ||=========================||
>>>>>>>>>>> | |
>>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second 
>>>>>>>>>>> "java -cp .
>>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>>> |
>>>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>>>> cases.
>>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>>> |
>>>>>>>>>>> |||
>>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior 
>>>>>>>>>>> (not
>>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>>> checking),
>>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>>> |
>>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I changed 
>>>>>>>>>> look
>>>>>>>>>> the
>>>>>>>>>> same as jdk 8.
>>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>>> |
>>>>>>>>>>> |||
>>>>>>>>>>> ||Thanks||
>>>>>>>>>>> ||- Ioi||
>>>>>>>>>>> ||
>>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>>> |
>>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>>> CHECK_
>>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>>> expect any
>>>>>>>>>>>> exceptions to be possible. I would check with Karen on 
>>>>>>>>>>>> this. ||
>>>>>>>>>>>> |
>>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>>> changes.
>>>>>>>>>> I can give it a try.
>>>>>>>>>> |
>>>>>>>>>>>> || |
>>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>>> |
>>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>>> It won't be needed if the method is declared with TRAPS as 
>>>>>>>>>> the last
>>>>>>>>>> parameter (I think).
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> Calvin
>>>>>>>>>> |
>>>>>>>>>>>> || |
>>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>>>> throwing
>>>>>>>>>>>> exceptions - don't know what the thought process was there 
>>>>>>>>>>>> :) ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||David ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>>> |
>>>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>>> similar
>>>>>>>>>>>>> crash ||
>>>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>>>> the ||
>>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>>> crash if
>>>>>>>>>>>>> the ||
>>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>>> ||} ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> above test ||
>>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>>>> thrown ||
>>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>>> ||         at 
>>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>>> Method) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> |
>>>>>>>>>>> |
>>>>>>>>>>> |
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>


From harold.seigel at oracle.com  Wed Aug 21 16:01:50 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 21 Aug 2013 19:01:50 -0400
Subject: RFR 8022183: GCC 4.56 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <52153ECD.9030006@oracle.com>
References: <52152EE3.2040804@oracle.com> <52153ECD.9030006@oracle.com>
Message-ID: <521546DE.8070000@oracle.com>

Thanks Dan!
Harold

On 8/21/2013 6:27 PM, Daniel D. Daugherty wrote:
> On 8/21/13 3:19 PM, harold seigel wrote:
>> Hi,
>>
>> Please review this small fix for bug 8022183.  This fix is needed in 
>> order to build hotspot on 32-bit Linux with newer versions of gcc. 
>> The fix explicitly specifies "-fno-omit-frame-pointer" in the 
>> makefile for 32-bit Linux.
>>
>> The fix was tested using NMT with -version and with GCBasher.
>>
>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/ 
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>
> make/linux/makefiles/i486.make
>     No comments.
>
> Thumbs up!
>
> Dan
>
>
>>
>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>>
>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>>
>> Thanks, Harold
>


From calvin.cheung at oracle.com  Wed Aug 21 17:01:51 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Wed, 21 Aug 2013 17:01:51 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52152ABE.5000804@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
	<52152ABE.5000804@oracle.com>
Message-ID: <521554EF.8030601@oracle.com>

On 8/21/2013 2:01 PM, Ioi Lam wrote:
> Calvin,
>
> I have not looked at the code in detail, but will your code now 
> repeatedly attempt to open the invalid JAR file? Maybe you can test 
> that by adding multiple Class.forName() calls in your tests (and 
> catching any exceptions).
public class test3 {
     public static void main(String[] args) {
         try {
             Class cls = Class.forName("xxx");
             System.out.println("Class = " + cls.getName());
             cls = Class.forName("yyy");
             System.out.println("Class = " + cls.getName());
         } catch (ClassNotFoundException cnfe) {
             cnfe.printStackTrace();
         }
     }
}

With the above test case, CNFE will be thrown for xxx and it won't try 
to load yyy.
>
> This is an error case (having an invalid JAR file in bootclasspath) so 
> performance is not important. However, if there's a simple way to 
> remember the result and never open the JAR file again that would be 
> ideal.
There's the following method in ClassLoader:
void ClassLoader::update_class_path_entry_list(const char *path,
                                                bool check_for_duplicates) {
   struct stat st;
   if (os::stat((char *)path, &st) == 0) {
     // File or directory found
     ClassPathEntry* new_entry = NULL;
     Thread* THREAD = Thread::current();
     create_class_path_entry((char *)path, st, &new_entry, 
LazyBootClassLoader, CHECK);
     // The kernel VM adds dynamically to the end of the classloader 
path and
     // doesn't reorder the bootclasspath which would break 
java.lang.Package
     // (see PackageInfo).
     // Add new entry to linked list
     if (!check_for_duplicates || !contains_entry(new_entry)) {
       add_to_list(new_entry);
     }
   }
}

With my fix, if create_class_path_entry() fails, it'll return without 
calling add_to_list().

thanks,
Calvin

>
> Thanks
> - Ioi
>
> On 08/21/2013 11:49 AM, Calvin Cheung wrote:
>> Can someone review this?
>>
>> Latest version:
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>
>> Previous version without using TRAPS:
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>>
>> thanks,
>> Calvin
>>
>> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>>> Hi David,
>>>
>>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>>> bit more and found that the error was thrown at a very early stage 
>>> within the init_globals() called from create_vm(). Below is the call 
>>> stack:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>> bytes    C++
>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) Line 
>>> 322 + 0x8 bytes C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1362 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 206 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
>>> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    
>>> C++
>>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
>>> Line 1904 + 0x9 bytes    C++
>>>      jvm.dll!Universe::genesis(Thread * __the_thread__)  Line 353 + 
>>> 0x9 bytes    C++
>>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
>>> >   jvm.dll!init_globals()  Line 114    C++
>>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
>>> args)  Line 5133 + 0xd bytes    C++
>>>      java.exe!011013bd()
>>>      [Frames below may be incorrect and/or missing, no symbols 
>>> loaded for java.exe]
>>>      java.exe!01101e2f()
>>>      java.exe!0110c807()
>>>      java.exe!0110a5a1()
>>>      java.exe!0110c845()
>>>      java.exe!0110a62b()
>>>      kernel32.dll!767633aa()
>>>      ntdll.dll!77739ef2()
>>>      ntdll.dll!77739ec5()
>>>
>>> The error was thrown in the method below:
>>> bool Exceptions::special_exception(Thread* thread, const char* file, 
>>> int line, Symbol* h_name, const char* message) {
>>>   // bootstrapping check
>>>   if (!Universe::is_fully_initialized()) {
>>>     if (h_name == NULL) {
>>>       // atleast an informative message.
>>>       vm_exit_during_initialization("Exception", message);
>>>     } else {
>>>       vm_exit_during_initialization(h_name, message);               
>>> <=====here
>>>     }
>>>     ShouldNotReachHere();
>>>   }
>>> }
>>>
>>> Note that it happened in the early stage during create_vm(), so the 
>>> (!Universe::is_fully_initialized()) was true.
>>>
>>> The class it was trying to load was sun/misc/AtomicLongCSImpl which 
>>> I couldn't find in 7u25.
>>> It was going through all the jar files in the bootclasspath and 
>>> finally got to the foo.jar which has 0-byte and got "error in 
>>> opening jar file" and then THROW_MSG().
>>> So I think it's just a coincident in 7u25 where the correct error 
>>> was thrown.
>>>
>>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>>> and thus it didn't hit the "error in opening jar file" (for the 
>>> foo.jar) early until it passed the point when the vm is considered 
>>> "initialized" - is_init_completed() is true. So when THROW_MSG() was 
>>> called when it tried to load the class specified by the test case 
>>> ("xxx"), it triggered the fatal error in ~ExceptionMark(). Call 
>>> stack up to the THROWN_MSG() as follows:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>> bytes    C++
>>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  
>>> Line 322 + 0x8 bytes    C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 900 + 0x17 bytes C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1301 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>>> name)  Line 773 + 0x12 bytes    C++
>>>      java.dll!69461e8c()
>>>      [Frames below may be incorrect and/or missing, no symbols 
>>> loaded for java.dll]
>>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>>> elem)  Line 207    C++
>>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>>> Line 375 + 0x11 bytes    C++
>>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * 
>>> thread)  Line 40 + 0x9 bytes    C++
>>>
>>> I'll try using TRAPS all the way through the call chain probably 
>>> starting from ClassLoader::load_classfile().
>>>
>>> thanks,
>>> Calvin
>>>
>>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>>> Hi Calvin,
>>>>
>>>> I don't think this works. As I said previously the expectations of 
>>>> this code with regard to Java exceptions seems to be that it 
>>>> doesn't expect them at all. If you are using TRAPS etc then it 
>>>> should be used all the way through the call chain. What we have now 
>>>> is this call sequence:
>>>>
>>>> void ClassLoader::initialize() {
>>>>   assert(_package_hash_table == NULL, "should have been initialized 
>>>> by now.");
>>>>   EXCEPTION_MARK;
>>>>   ...
>>>>   setup_bootstrap_search_path();
>>>>     -> update_class_path_entry_list(path, false);
>>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>>> LazyBootClassLoader, CHECK);
>>>>
>>>> So if we return after the call to create_class_path_entry with an 
>>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>>
>>>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>>>> exception check and a vm_exit_during_initialization, if this 
>>>> exception can readily occur at runtime. But further analysis of all 
>>>> this code needs to be undertaken.
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>>> I've updated the webrev with 2 changes:
>>>>> 1) added the TRAPS as the last parameter to the
>>>>> create_class_path_entry() method;
>>>>> 2) added a jtreg test case.
>>>>>
>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>
>>>>> Please take a look again.
>>>>>
>>>>> One more response in-lined below...
>>>>>
>>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>>> |I found one version of JDK7 that does not crash:||
>>>>>> ||
>>>>>> sc11136754 ~$
>>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>>
>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>> Error occurred during initialization of VM
>>>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>>>> |
>>>>>
>>>>> |I noticed that it started breaking in 7u40 b01; it was still working
>>>>> with 7u25.
>>>>> It may have something to do with when the set_init_completed() is 
>>>>> called:
>>>>> ExceptionMark::~ExceptionMark() {
>>>>>    if (_thread->has_pending_exception()) {
>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>> recursion
>>>>>      if (is_init_completed()) {
>>>>>        exception->print();
>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>> exceptions");
>>>>>      } else {
>>>>>        vm_exit_during_initialization(exception);
>>>>>      }
>>>>>    }
>>>>> }
>>>>>
>>>>> Before 7u40, I think the code path got to the "else" branch of
>>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>>
>>>>> set_init_completed() is only called from Threads::create_vm() and 
>>>>> that
>>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>>>>>
>>>>> Debugging with hs25, the set_init_completed() always happened before
>>>>> create_class_path_entry() and both calls were done within the same
>>>>> thread - "vm startup".
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>>
>>>>> |
>>>>>> |||
>>>>>> ||
>>>>>> ||- Ioi
>>>>>> |
>>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>>> |I found an official version that's closest to the Redhat version
>>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>>> crashes.||
>>>>>>> ||
>>>>>>> ||sc11136754 ~$
>>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>> ||java version "1.6.0_25"||
>>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>> ||
>>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>>> ||#||
>>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>>> Environment:||
>>>>>>> ||#||
>>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>>> tid=140608485558016||
>>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>>> exceptions||
>>>>>>> ||#||
>>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>>>>>> linux-amd64 compressed oops)||
>>>>>>> ||# An error report file with more information is saved as:||
>>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>>> ||#||
>>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>>> ||#||
>>>>>>> ||Aborted (core dumped)||
>>>>>>> |
>>>>>>> - Ioi
>>>>>>>
>>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>>> apparently
>>>>>>>>> works differently
>>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed 
>>>>>>>>> this in
>>>>>>>>> their
>>>>>>>>> own repo??||
>>>>>>>>
>>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> ||
>>>>>>>>> |
>>>>>>>>> |==OEL6================================================
>>>>>>>>> ||
>>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>>>>>> test2||
>>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>>> foo.jar||
>>>>>>>>> ||
>>>>>>>>> ==OFFICIAL============================================
>>>>>>>>> ||
>>>>>>>>> sc11136754 ~$ 
>>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>>> java version "1.6.0_22"
>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>>
>>>>>>>>> #
>>>>>>>>> # A fatal error has been detected by the Java Runtime 
>>>>>>>>> Environment:
>>>>>>>>> #
>>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>>> tid=140510319580928
>>>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>>>> #
>>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>>>>>> linux-amd64 )
>>>>>>>>> # An error report file with more information is saved as:
>>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>>> #
>>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>>> #
>>>>>>>>> |
>>>>>>>>> |======================================================
>>>>>>>>> ||
>>>>>>>>> ||- Ioi|
>>>>>>>>>
>>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>>> Hi Ioi, David,
>>>>>>>>>>
>>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>>> files in
>>>>>>>>>>> the JDK:||
>>>>>>>>>>> ||
>>>>>>>>>>> ||=========================||
>>>>>>>>>>> ||/*||
>>>>>>>>>>> ||javac test2.java||
>>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>> ||*/||
>>>>>>>>>>> ||
>>>>>>>>>>> ||public class test2 {||
>>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>>> ||        try {||
>>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>>> ||        }||
>>>>>>>>>>> ||    }||
>>>>>>>>>>> ||}||
>>>>>>>>>>> ||=========================||
>>>>>>>>>>> | |
>>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second 
>>>>>>>>>>> "java -cp .
>>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>>> |
>>>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>>>> cases.
>>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>>> |
>>>>>>>>>>> |||
>>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior 
>>>>>>>>>>> (not
>>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>>> checking),
>>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>>> |
>>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I changed 
>>>>>>>>>> look
>>>>>>>>>> the
>>>>>>>>>> same as jdk 8.
>>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>>> |
>>>>>>>>>>> |||
>>>>>>>>>>> ||Thanks||
>>>>>>>>>>> ||- Ioi||
>>>>>>>>>>> ||
>>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>>> |
>>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>>> CHECK_
>>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>>> expect any
>>>>>>>>>>>> exceptions to be possible. I would check with Karen on 
>>>>>>>>>>>> this. ||
>>>>>>>>>>>> |
>>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>>> changes.
>>>>>>>>>> I can give it a try.
>>>>>>>>>> |
>>>>>>>>>>>> || |
>>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>>> |
>>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>>> It won't be needed if the method is declared with TRAPS as 
>>>>>>>>>> the last
>>>>>>>>>> parameter (I think).
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> Calvin
>>>>>>>>>> |
>>>>>>>>>>>> || |
>>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>>>> throwing
>>>>>>>>>>>> exceptions - don't know what the thought process was there 
>>>>>>>>>>>> :) ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||David ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>>> |
>>>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>>> similar
>>>>>>>>>>>>> crash ||
>>>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>>>> the ||
>>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>>> crash if
>>>>>>>>>>>>> the ||
>>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>>> ||} ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> above test ||
>>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>>>> thrown ||
>>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>>> ||         at 
>>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>>> Method) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> |
>>>>>>>>>>> |
>>>>>>>>>>> |
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>


From david.holmes at oracle.com  Wed Aug 21 20:19:20 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 22 Aug 2013 13:19:20 +1000
Subject: RFR 8022183: GCC 4.56 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <52152EE3.2040804@oracle.com>
References: <52152EE3.2040804@oracle.com>
Message-ID: <52158338.8020003@oracle.com>

Hi Harold,

I know you modelled this on the code in amd64.make but it really seems 
to me that this belongs in gcc.make. Note that gcc.make already contains 
related flags for clang:

ifeq ($(USE_CLANG), true)
   # Before Clang 3.1, we had to pass the stack alignment specification 
directly to llvm with the help of '-mllvm'
   # Starting with version 3.1, Clang understands the 
'-mstack-alignment' (and rejects '-mllvm -stack-alignment')
   ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 3 \) \| \( \( 
$(CC_VER_MAJOR) = 3 \) \& \( $(CC_VER_MINOR) \>= 1 \) \))" "0"
     STACK_ALIGNMENT_OPT = -mno-omit-leaf-frame-pointer -mstack-alignment=16
   else
     STACK_ALIGNMENT_OPT = -mno-omit-leaf-frame-pointer -mllvm 
-stack-alignment=16
   endif
endif

If placed in gcc.make the code in amd64.make could be removed.

Hmmm, it also seems to me that this change will also add the flag for 
clang (as does the existing amd5=64 code). I'm unsure if that is good or 
bad? Maybe one of our clang experts could chime in if they are on this list.

Thanks,
David

On 22/08/2013 7:19 AM, harold seigel wrote:
> Hi,
>
> Please review this small fix for bug 8022183.  This fix is needed in
> order to build hotspot on 32-bit Linux with newer versions of gcc. The
> fix explicitly specifies "-fno-omit-frame-pointer" in the makefile for
> 32-bit Linux.
>
> The fix was tested using NMT with -version and with GCBasher.
>
> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>
> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>
> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>
> Thanks, Harold

From ioi.lam at oracle.com  Wed Aug 21 20:35:33 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 21 Aug 2013 20:35:33 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <521554EF.8030601@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
	<52152ABE.5000804@oracle.com> <521554EF.8030601@oracle.com>
Message-ID: <52158705.2080205@oracle.com>

On 08/21/2013 05:01 PM, Calvin Cheung wrote:
> On 8/21/2013 2:01 PM, Ioi Lam wrote:
>> Calvin,
>>
>> I have not looked at the code in detail, but will your code now 
>> repeatedly attempt to open the invalid JAR file? Maybe you can test 
>> that by adding multiple Class.forName() calls in your tests (and 
>> catching any exceptions).
> public class test3 {
>     public static void main(String[] args) {
>         try {
>             Class cls = Class.forName("xxx");
>             System.out.println("Class = " + cls.getName());
>             cls = Class.forName("yyy");
>             System.out.println("Class = " + cls.getName());
>         } catch (ClassNotFoundException cnfe) {
>             cnfe.printStackTrace();
>         }
>     }
> }
>
How about changing it to do this:

      try {
             Class.forName("xxx");
       } catch (ClassNotFoundException cnfe) {
             cnfe.printStackTrace();
       }
       try {
             Class.forName("yyy");
       } catch (ClassNotFoundException cnfe) {
             cnfe.printStackTrace();
       }

I think you will find that create_class_path_entry will be called twice 
for the invalid JAR file with lazy==false.

> With the above test case, CNFE will be thrown for xxx and it won't try 
> to load yyy.
>>
>> This is an error case (having an invalid JAR file in bootclasspath) 
>> so performance is not important. However, if there's a simple way to 
>> remember the result and never open the JAR file again that would be 
>> ideal.
> There's the following method in ClassLoader:
> void ClassLoader::update_class_path_entry_list(const char *path,
>                                                bool 
> check_for_duplicates) {
>   struct stat st;
>   if (os::stat((char *)path, &st) == 0) {
>     // File or directory found
>     ClassPathEntry* new_entry = NULL;
>     Thread* THREAD = Thread::current();
>     create_class_path_entry((char *)path, st, &new_entry, 
> LazyBootClassLoader, CHECK);
>     // The kernel VM adds dynamically to the end of the classloader 
> path and
>     // doesn't reorder the bootclasspath which would break 
> java.lang.Package
>     // (see PackageInfo).
>     // Add new entry to linked list
>     if (!check_for_duplicates || !contains_entry(new_entry)) {
>       add_to_list(new_entry);
>     }
>   }
> }
>
> With my fix, if create_class_path_entry() fails, it'll return without 
> calling add_to_list().

I think you should do this to avoid the repeated opening of the invalid 
JAR file:

317 ClassFileStream* LazyClassPathEntry::open_stream(const char* name) {
  318   if (_meta_index != NULL &&
  319       !_meta_index->may_contain(name)) {
  320     return NULL;
  321   }
        if (_has_error) { // add a new field bool 
LazyClassPathEntry::_has_error;
          return NULL;
        }
  322   ClassPathEntry* cpe = resolve_entry();
        if (cpe == NULL) {
          _has_error = true;
          return NULL;
        } else {
          return cpe->open_stream(name);
  324 }

Also, since you're changing the signature of 
ClassLoader::create_class_path_entry(),
I think you can perform onemore clean up:

void ClassLoader::create_class_path_entry(char *path, const struct stat* 
st, ClassPathEntry **new_entry, bool lazy, TRAPS)

=>

ClassPathEntry* ClassLoader::create_class_path_entry(char *path, struct 
stat st, bool lazy, TRAPS)

It just doesn't make sense to return void and set the returned value in 
a pointer ...

Also, the st structure is pretty big (88 bytes on linux 32 bits, 144 
bytes on 64 bits). It's better to use a pointer. You can declare it 
const to make sure that the callee doesn't modify it.


Thanks
- Ioi

>
> thanks,
> Calvin
>
>>
>> Thanks
>> - Ioi
>>
>> On 08/21/2013 11:49 AM, Calvin Cheung wrote:
>>> Can someone review this?
>>>
>>> Latest version:
>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>
>>> Previous version without using TRAPS:
>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>>>
>>> thanks,
>>> Calvin
>>>
>>> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>>>> Hi David,
>>>>
>>>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>>>> bit more and found that the error was thrown at a very early stage 
>>>> within the init_globals() called from create_vm(). Below is the 
>>>> call stack:
>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>>> st, ClassPathEntry * * new_entry, bool lazy) Line 508 C++
>>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>>> bytes    C++
>>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) 
>>>> Line 322 + 0x8 bytes C++
>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1362 
>>>> + 0x14 bytes    C++
>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 206 + 0x15 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>>>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID id, 
>>>> int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    C++
>>>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>>>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>>>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>>>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>>>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>>>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
>>>> Line 1904 + 0x9 bytes    C++
>>>>      jvm.dll!Universe::genesis(Thread * __the_thread__) Line 353 + 
>>>> 0x9 bytes    C++
>>>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
>>>> >   jvm.dll!init_globals()  Line 114    C++
>>>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>>>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
>>>> args)  Line 5133 + 0xd bytes    C++
>>>>      java.exe!011013bd()
>>>>      [Frames below may be incorrect and/or missing, no symbols 
>>>> loaded for java.exe]
>>>>      java.exe!01101e2f()
>>>>      java.exe!0110c807()
>>>>      java.exe!0110a5a1()
>>>>      java.exe!0110c845()
>>>>      java.exe!0110a62b()
>>>>      kernel32.dll!767633aa()
>>>>      ntdll.dll!77739ef2()
>>>>      ntdll.dll!77739ec5()
>>>>
>>>> The error was thrown in the method below:
>>>> bool Exceptions::special_exception(Thread* thread, const char* 
>>>> file, int line, Symbol* h_name, const char* message) {
>>>>   // bootstrapping check
>>>>   if (!Universe::is_fully_initialized()) {
>>>>     if (h_name == NULL) {
>>>>       // atleast an informative message.
>>>>       vm_exit_during_initialization("Exception", message);
>>>>     } else {
>>>>       vm_exit_during_initialization(h_name, message);               
>>>> <=====here
>>>>     }
>>>>     ShouldNotReachHere();
>>>>   }
>>>> }
>>>>
>>>> Note that it happened in the early stage during create_vm(), so the 
>>>> (!Universe::is_fully_initialized()) was true.
>>>>
>>>> The class it was trying to load was sun/misc/AtomicLongCSImpl which 
>>>> I couldn't find in 7u25.
>>>> It was going through all the jar files in the bootclasspath and 
>>>> finally got to the foo.jar which has 0-byte and got "error in 
>>>> opening jar file" and then THROW_MSG().
>>>> So I think it's just a coincident in 7u25 where the correct error 
>>>> was thrown.
>>>>
>>>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>>>> and thus it didn't hit the "error in opening jar file" (for the 
>>>> foo.jar) early until it passed the point when the vm is considered 
>>>> "initialized" - is_init_completed() is true. So when THROW_MSG() 
>>>> was called when it tried to load the class specified by the test 
>>>> case ("xxx"), it triggered the fatal error in ~ExceptionMark(). 
>>>> Call stack up to the THROWN_MSG() as follows:
>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>>> st, ClassPathEntry * * new_entry, bool lazy) Line 508 C++
>>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>>> bytes    C++
>>>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  
>>>> Line 322 + 0x8 bytes    C++
>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>> __the_thread__)  Line 900 + 0x17 bytes C++
>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1301 
>>>> + 0x14 bytes    C++
>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char 
>>>> * name)  Line 773 + 0x12 bytes    C++
>>>>      java.dll!69461e8c()
>>>>      [Frames below may be incorrect and/or missing, no symbols 
>>>> loaded for java.dll]
>>>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>>>> elem)  Line 207    C++
>>>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>>>> Line 375 + 0x11 bytes    C++
>>>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * 
>>>> thread)  Line 40 + 0x9 bytes    C++
>>>>
>>>> I'll try using TRAPS all the way through the call chain probably 
>>>> starting from ClassLoader::load_classfile().
>>>>
>>>> thanks,
>>>> Calvin
>>>>
>>>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>>>> Hi Calvin,
>>>>>
>>>>> I don't think this works. As I said previously the expectations of 
>>>>> this code with regard to Java exceptions seems to be that it 
>>>>> doesn't expect them at all. If you are using TRAPS etc then it 
>>>>> should be used all the way through the call chain. What we have 
>>>>> now is this call sequence:
>>>>>
>>>>> void ClassLoader::initialize() {
>>>>>   assert(_package_hash_table == NULL, "should have been 
>>>>> initialized by now.");
>>>>>   EXCEPTION_MARK;
>>>>>   ...
>>>>>   setup_bootstrap_search_path();
>>>>>     -> update_class_path_entry_list(path, false);
>>>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>>>> LazyBootClassLoader, CHECK);
>>>>>
>>>>> So if we return after the call to create_class_path_entry with an 
>>>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>>>
>>>>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>>>>> exception check and a vm_exit_during_initialization, if this 
>>>>> exception can readily occur at runtime. But further analysis of 
>>>>> all this code needs to be undertaken.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>>>> I've updated the webrev with 2 changes:
>>>>>> 1) added the TRAPS as the last parameter to the
>>>>>> create_class_path_entry() method;
>>>>>> 2) added a jtreg test case.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>>
>>>>>> Please take a look again.
>>>>>>
>>>>>> One more response in-lined below...
>>>>>>
>>>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>>>> |I found one version of JDK7 that does not crash:||
>>>>>>> ||
>>>>>>> sc11136754 ~$
>>>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>>>
>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>> Error occurred during initialization of VM
>>>>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>>>>> |
>>>>>>
>>>>>> |I noticed that it started breaking in 7u40 b01; it was still 
>>>>>> working
>>>>>> with 7u25.
>>>>>> It may have something to do with when the set_init_completed() is 
>>>>>> called:
>>>>>> ExceptionMark::~ExceptionMark() {
>>>>>>    if (_thread->has_pending_exception()) {
>>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>>> recursion
>>>>>>      if (is_init_completed()) {
>>>>>>        exception->print();
>>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>>> exceptions");
>>>>>>      } else {
>>>>>>        vm_exit_during_initialization(exception);
>>>>>>      }
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>> Before 7u40, I think the code path got to the "else" branch of
>>>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>>>
>>>>>> set_init_completed() is only called from Threads::create_vm() and 
>>>>>> that
>>>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by 
>>>>>> default?
>>>>>>
>>>>>> Debugging with hs25, the set_init_completed() always happened before
>>>>>> create_class_path_entry() and both calls were done within the same
>>>>>> thread - "vm startup".
>>>>>>
>>>>>> thanks,
>>>>>> Calvin
>>>>>>
>>>>>>
>>>>>> |
>>>>>>> |||
>>>>>>> ||
>>>>>>> ||- Ioi
>>>>>>> |
>>>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>>>> |I found an official version that's closest to the Redhat version
>>>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>>>> crashes.||
>>>>>>>> ||
>>>>>>>> ||sc11136754 ~$
>>>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java 
>>>>>>>> -showversion
>>>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>> ||java version "1.6.0_25"||
>>>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>> ||
>>>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>>>> ||#||
>>>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>>>> Environment:||
>>>>>>>> ||#||
>>>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>>>> tid=140608485558016||
>>>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>>>> exceptions||
>>>>>>>> ||#||
>>>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed 
>>>>>>>> mode
>>>>>>>> linux-amd64 compressed oops)||
>>>>>>>> ||# An error report file with more information is saved as:||
>>>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>>>> ||#||
>>>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>>>> ||#||
>>>>>>>> ||Aborted (core dumped)||
>>>>>>>> |
>>>>>>>> - Ioi
>>>>>>>>
>>>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>>>> apparently
>>>>>>>>>> works differently
>>>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed 
>>>>>>>>>> this in
>>>>>>>>>> their
>>>>>>>>>> own repo??||
>>>>>>>>>
>>>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> ||
>>>>>>>>>> |
>>>>>>>>>> |==OEL6================================================
>>>>>>>>>> ||
>>>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>>>> ||sc11136754 ~$ java -showversion -cp . 
>>>>>>>>>> -Xbootclasspath/a:foo.jar
>>>>>>>>>> test2||
>>>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>>>> foo.jar||
>>>>>>>>>> ||
>>>>>>>>>> ==OFFICIAL============================================
>>>>>>>>>> ||
>>>>>>>>>> sc11136754 ~$ 
>>>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>>>> java version "1.6.0_22"
>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>>>
>>>>>>>>>> #
>>>>>>>>>> # A fatal error has been detected by the Java Runtime 
>>>>>>>>>> Environment:
>>>>>>>>>> #
>>>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>>>> tid=140510319580928
>>>>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>>>>> #
>>>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed 
>>>>>>>>>> mode
>>>>>>>>>> linux-amd64 )
>>>>>>>>>> # An error report file with more information is saved as:
>>>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>>>> #
>>>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>>>> #
>>>>>>>>>> |
>>>>>>>>>> |======================================================
>>>>>>>>>> ||
>>>>>>>>>> ||- Ioi|
>>>>>>>>>>
>>>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>>>> Hi Ioi, David,
>>>>>>>>>>>
>>>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>>>> files in
>>>>>>>>>>>> the JDK:||
>>>>>>>>>>>> ||
>>>>>>>>>>>> ||=========================||
>>>>>>>>>>>> ||/*||
>>>>>>>>>>>> ||javac test2.java||
>>>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>>> ||*/||
>>>>>>>>>>>> ||
>>>>>>>>>>>> ||public class test2 {||
>>>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>>>> ||        try {||
>>>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>>>> ||        }||
>>>>>>>>>>>> ||    }||
>>>>>>>>>>>> ||}||
>>>>>>>>>>>> ||=========================||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second 
>>>>>>>>>>>> "java -cp .
>>>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>>>> |
>>>>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>>>>> cases.
>>>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>>>> |
>>>>>>>>>>>> |||
>>>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 
>>>>>>>>>>>> behavior (not
>>>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>>>> checking),
>>>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>>>> |
>>>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I 
>>>>>>>>>>> changed look
>>>>>>>>>>> the
>>>>>>>>>>> same as jdk 8.
>>>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>>>> |
>>>>>>>>>>>> |||
>>>>>>>>>>>> ||Thanks||
>>>>>>>>>>>> ||- Ioi||
>>>>>>>>>>>> ||
>>>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>>>> |
>>>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>>>> exceptions. If exceptions can be posted then methods 
>>>>>>>>>>>>> should be
>>>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>>>> CHECK_
>>>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>>>> expect any
>>>>>>>>>>>>> exceptions to be possible. I would check with Karen on 
>>>>>>>>>>>>> this. ||
>>>>>>>>>>>>> |
>>>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>>>> changes.
>>>>>>>>>>> I can give it a try.
>>>>>>>>>>> |
>>>>>>>>>>>>> || |
>>>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>>>> |
>>>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>>>> It won't be needed if the method is declared with TRAPS as 
>>>>>>>>>>> the last
>>>>>>>>>>> parameter (I think).
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>> Calvin
>>>>>>>>>>> |
>>>>>>>>>>>>> || |
>>>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>>>>> throwing
>>>>>>>>>>>>> exceptions - don't know what the thought process was there 
>>>>>>>>>>>>> :) ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||David ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>>>> |
>>>>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>>>> similar
>>>>>>>>>>>>>> crash ||
>>>>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>>>>> the ||
>>>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>>>> crash if
>>>>>>>>>>>>>> the ||
>>>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>>>> ||} ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail 
>>>>>>>>>>>>>> under the
>>>>>>>>>>>>>> above test ||
>>>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>>>>> thrown ||
>>>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>>>> ||         at 
>>>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>>>> Method) ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) || 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>>>> ||
>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> |
>>>>>>>>>>>> |
>>>>>>>>>>>> |
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>


From ioi.lam at oracle.com  Wed Aug 21 20:45:02 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 21 Aug 2013 20:45:02 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52158705.2080205@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
	<52152ABE.5000804@oracle.com> <521554EF.8030601@oracle.com>
	<52158705.2080205@oracle.com>
Message-ID: <5215893E.9090605@oracle.com>

Oh, and while you're at it. this also needs to be cleaned up. The path 
argument to update_class_path_entry_list() shouldn't be const -- it may 
be modified by os::native_path (see os_windows.cpp). Also, 
update_class_path_entry_list() is called from a single place, where the 
path is malloc'ed so it's definitely modifiable.


Thanks

- Ioi

--- a/src/share/vm/classfile/classLoader.cpp    Mon Aug 05 10:29:35 2013 
-0700
+++ b/src/share/vm/classfile/classLoader.cpp    Wed Aug 21 20:40:29 2013 
-0700
@@ -572,13 +572,13 @@
    }
  }

-void ClassLoader::update_class_path_entry_list(const char *path,
+void ClassLoader::update_class_path_entry_list(char *path,
                                                 bool 
check_for_duplicates) {
    struct stat st;
-  if (os::stat((char *)path, &st) == 0) {
+  if (os::stat(path, &st) == 0) {
      // File or directory found
      ClassPathEntry* new_entry = NULL;
-    create_class_path_entry((char *)path, st, &new_entry, 
LazyBootClassLoader);
+    create_class_path_entry(path, st, &new_entry, LazyBootClassLoader);
      // The kernel VM adds dynamically to the end of the classloader 
path and
      // doesn't reorder the bootclasspath which would break 
java.lang.Package
      // (see PackageInfo).
diff -r 055c29438400 src/share/vm/classfile/classLoader.hpp
--- a/src/share/vm/classfile/classLoader.hpp    Mon Aug 05 10:29:35 2013 
-0700
+++ b/src/share/vm/classfile/classLoader.hpp    Wed Aug 21 20:40:29 2013 
-0700
@@ -214,7 +214,7 @@
    static bool get_canonical_path(char* orig, char* out, int len);
   public:
    // Used by the kernel jvm.
-  static void update_class_path_entry_list(const char *path,
+  static void update_class_path_entry_list(char *path,
                                             bool check_for_duplicates);
    static void print_bootclasspath();




On 08/21/2013 08:35 PM, Ioi Lam wrote:
> On 08/21/2013 05:01 PM, Calvin Cheung wrote:
>> On 8/21/2013 2:01 PM, Ioi Lam wrote:
>>> Calvin,
>>>
>>> I have not looked at the code in detail, but will your code now 
>>> repeatedly attempt to open the invalid JAR file? Maybe you can test 
>>> that by adding multiple Class.forName() calls in your tests (and 
>>> catching any exceptions).
>> public class test3 {
>>     public static void main(String[] args) {
>>         try {
>>             Class cls = Class.forName("xxx");
>>             System.out.println("Class = " + cls.getName());
>>             cls = Class.forName("yyy");
>>             System.out.println("Class = " + cls.getName());
>>         } catch (ClassNotFoundException cnfe) {
>>             cnfe.printStackTrace();
>>         }
>>     }
>> }
>>
> How about changing it to do this:
>
>      try {
>             Class.forName("xxx");
>       } catch (ClassNotFoundException cnfe) {
>             cnfe.printStackTrace();
>       }
>       try {
>             Class.forName("yyy");
>       } catch (ClassNotFoundException cnfe) {
>             cnfe.printStackTrace();
>       }
>
> I think you will find that create_class_path_entry will be called 
> twice for the invalid JAR file with lazy==false.
>
>> With the above test case, CNFE will be thrown for xxx and it won't 
>> try to load yyy.
>>>
>>> This is an error case (having an invalid JAR file in bootclasspath) 
>>> so performance is not important. However, if there's a simple way to 
>>> remember the result and never open the JAR file again that would be 
>>> ideal.
>> There's the following method in ClassLoader:
>> void ClassLoader::update_class_path_entry_list(const char *path,
>>                                                bool 
>> check_for_duplicates) {
>>   struct stat st;
>>   if (os::stat((char *)path, &st) == 0) {
>>     // File or directory found
>>     ClassPathEntry* new_entry = NULL;
>>     Thread* THREAD = Thread::current();
>>     create_class_path_entry((char *)path, st, &new_entry, 
>> LazyBootClassLoader, CHECK);
>>     // The kernel VM adds dynamically to the end of the classloader 
>> path and
>>     // doesn't reorder the bootclasspath which would break 
>> java.lang.Package
>>     // (see PackageInfo).
>>     // Add new entry to linked list
>>     if (!check_for_duplicates || !contains_entry(new_entry)) {
>>       add_to_list(new_entry);
>>     }
>>   }
>> }
>>
>> With my fix, if create_class_path_entry() fails, it'll return without 
>> calling add_to_list().
>
> I think you should do this to avoid the repeated opening of the 
> invalid JAR file:
>
> 317 ClassFileStream* LazyClassPathEntry::open_stream(const char* name) {
>  318   if (_meta_index != NULL &&
>  319       !_meta_index->may_contain(name)) {
>  320     return NULL;
>  321   }
>        if (_has_error) { // add a new field bool 
> LazyClassPathEntry::_has_error;
>          return NULL;
>        }
>  322   ClassPathEntry* cpe = resolve_entry();
>        if (cpe == NULL) {
>          _has_error = true;
>          return NULL;
>        } else {
>          return cpe->open_stream(name);
>  324 }
>
> Also, since you're changing the signature of 
> ClassLoader::create_class_path_entry(),
> I think you can perform onemore clean up:
>
> void ClassLoader::create_class_path_entry(char *path, const struct 
> stat* st, ClassPathEntry **new_entry, bool lazy, TRAPS)
>
> =>
>
> ClassPathEntry* ClassLoader::create_class_path_entry(char *path, 
> struct stat st, bool lazy, TRAPS)
>
> It just doesn't make sense to return void and set the returned value 
> in a pointer ...
>
> Also, the st structure is pretty big (88 bytes on linux 32 bits, 144 
> bytes on 64 bits). It's better to use a pointer. You can declare it 
> const to make sure that the callee doesn't modify it.
>
>
> Thanks
> - Ioi
>
>>
>> thanks,
>> Calvin
>>
>>>
>>> Thanks
>>> - Ioi
>>>
>>> On 08/21/2013 11:49 AM, Calvin Cheung wrote:
>>>> Can someone review this?
>>>>
>>>> Latest version:
>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>
>>>> Previous version without using TRAPS:
>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>>>>
>>>> thanks,
>>>> Calvin
>>>>
>>>> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>>>>> Hi David,
>>>>>
>>>>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>>>>> bit more and found that the error was thrown at a very early stage 
>>>>> within the init_globals() called from create_vm(). Below is the 
>>>>> call stack:
>>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, 
>>>>> stat st, ClassPathEntry * * new_entry, bool lazy) Line 508 C++
>>>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>>>> bytes    C++
>>>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) 
>>>>> Line 322 + 0x8 bytes C++
>>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>>> class_name, Handle class_loader, Thread * __the_thread__) Line 
>>>>> 1362 + 0x14 bytes    C++
>>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * 
>>>>> class_name, Handle class_loader, Handle protection_domain, Thread 
>>>>> * __the_thread__)  Line 206 + 0x15 bytes    C++
>>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * 
>>>>> class_name, Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>>>>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
>>>>> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd 
>>>>> bytes    C++
>>>>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>>>>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>>>>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>>>>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>>>>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>>>>      jvm.dll!SystemDictionary::initialize(Thread * 
>>>>> __the_thread__)  Line 1904 + 0x9 bytes    C++
>>>>>      jvm.dll!Universe::genesis(Thread * __the_thread__) Line 353 + 
>>>>> 0x9 bytes    C++
>>>>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes C++
>>>>> >   jvm.dll!init_globals()  Line 114    C++
>>>>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>>>>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>>>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void 
>>>>> * args)  Line 5133 + 0xd bytes    C++
>>>>>      java.exe!011013bd()
>>>>>      [Frames below may be incorrect and/or missing, no symbols 
>>>>> loaded for java.exe]
>>>>>      java.exe!01101e2f()
>>>>>      java.exe!0110c807()
>>>>>      java.exe!0110a5a1()
>>>>>      java.exe!0110c845()
>>>>>      java.exe!0110a62b()
>>>>>      kernel32.dll!767633aa()
>>>>>      ntdll.dll!77739ef2()
>>>>>      ntdll.dll!77739ec5()
>>>>>
>>>>> The error was thrown in the method below:
>>>>> bool Exceptions::special_exception(Thread* thread, const char* 
>>>>> file, int line, Symbol* h_name, const char* message) {
>>>>>   // bootstrapping check
>>>>>   if (!Universe::is_fully_initialized()) {
>>>>>     if (h_name == NULL) {
>>>>>       // atleast an informative message.
>>>>>       vm_exit_during_initialization("Exception", message);
>>>>>     } else {
>>>>>       vm_exit_during_initialization(h_name, 
>>>>> message);               <=====here
>>>>>     }
>>>>>     ShouldNotReachHere();
>>>>>   }
>>>>> }
>>>>>
>>>>> Note that it happened in the early stage during create_vm(), so 
>>>>> the (!Universe::is_fully_initialized()) was true.
>>>>>
>>>>> The class it was trying to load was sun/misc/AtomicLongCSImpl 
>>>>> which I couldn't find in 7u25.
>>>>> It was going through all the jar files in the bootclasspath and 
>>>>> finally got to the foo.jar which has 0-byte and got "error in 
>>>>> opening jar file" and then THROW_MSG().
>>>>> So I think it's just a coincident in 7u25 where the correct error 
>>>>> was thrown.
>>>>>
>>>>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>>>>> and thus it didn't hit the "error in opening jar file" (for the 
>>>>> foo.jar) early until it passed the point when the vm is considered 
>>>>> "initialized" - is_init_completed() is true. So when THROW_MSG() 
>>>>> was called when it tried to load the class specified by the test 
>>>>> case ("xxx"), it triggered the fatal error in ~ExceptionMark(). 
>>>>> Call stack up to the THROWN_MSG() as follows:
>>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, 
>>>>> stat st, ClassPathEntry * * new_entry, bool lazy) Line 508 C++
>>>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>>>> bytes    C++
>>>>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  
>>>>> Line 322 + 0x8 bytes    C++
>>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>>> __the_thread__)  Line 900 + 0x17 bytes C++
>>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>>> class_name, Handle class_loader, Thread * __the_thread__) Line 
>>>>> 1301 + 0x14 bytes    C++
>>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * 
>>>>> class_name, Handle class_loader, Handle protection_domain, Thread 
>>>>> * __the_thread__)  Line 232 + 0x15 bytes    C++
>>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * 
>>>>> class_name, Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>>>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char 
>>>>> * name)  Line 773 + 0x12 bytes    C++
>>>>>      java.dll!69461e8c()
>>>>>      [Frames below may be incorrect and/or missing, no symbols 
>>>>> loaded for java.dll]
>>>>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>>>>> elem)  Line 207 C++
>>>>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>>>>> Line 375 + 0x11 bytes    C++
>>>>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * 
>>>>> thread)  Line 40 + 0x9 bytes    C++
>>>>>
>>>>> I'll try using TRAPS all the way through the call chain probably 
>>>>> starting from ClassLoader::load_classfile().
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>>>>> Hi Calvin,
>>>>>>
>>>>>> I don't think this works. As I said previously the expectations 
>>>>>> of this code with regard to Java exceptions seems to be that it 
>>>>>> doesn't expect them at all. If you are using TRAPS etc then it 
>>>>>> should be used all the way through the call chain. What we have 
>>>>>> now is this call sequence:
>>>>>>
>>>>>> void ClassLoader::initialize() {
>>>>>>   assert(_package_hash_table == NULL, "should have been 
>>>>>> initialized by now.");
>>>>>>   EXCEPTION_MARK;
>>>>>>   ...
>>>>>>   setup_bootstrap_search_path();
>>>>>>     -> update_class_path_entry_list(path, false);
>>>>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>>>>> LazyBootClassLoader, CHECK);
>>>>>>
>>>>>> So if we return after the call to create_class_path_entry with an 
>>>>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>>>>
>>>>>> It may be that the EXCEPTION_MARK needs replacing with an 
>>>>>> explicit exception check and a vm_exit_during_initialization, if 
>>>>>> this exception can readily occur at runtime. But further analysis 
>>>>>> of all this code needs to be undertaken.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>>>>> I've updated the webrev with 2 changes:
>>>>>>> 1) added the TRAPS as the last parameter to the
>>>>>>> create_class_path_entry() method;
>>>>>>> 2) added a jtreg test case.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>>>
>>>>>>> Please take a look again.
>>>>>>>
>>>>>>> One more response in-lined below...
>>>>>>>
>>>>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>>>>> |I found one version of JDK7 that does not crash:||
>>>>>>>> ||
>>>>>>>> sc11136754 ~$
>>>>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>>>>
>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>> Error occurred during initialization of VM
>>>>>>>> java/lang/ClassNotFoundException: error in opening JAR file 
>>>>>>>> foo.jar
>>>>>>>> |
>>>>>>>
>>>>>>> |I noticed that it started breaking in 7u40 b01; it was still 
>>>>>>> working
>>>>>>> with 7u25.
>>>>>>> It may have something to do with when the set_init_completed() 
>>>>>>> is called:
>>>>>>> ExceptionMark::~ExceptionMark() {
>>>>>>>    if (_thread->has_pending_exception()) {
>>>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>>>      _thread->clear_pending_exception(); // Needed to avoid 
>>>>>>> infinite
>>>>>>> recursion
>>>>>>>      if (is_init_completed()) {
>>>>>>>        exception->print();
>>>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>>>> exceptions");
>>>>>>>      } else {
>>>>>>>        vm_exit_during_initialization(exception);
>>>>>>>      }
>>>>>>>    }
>>>>>>> }
>>>>>>>
>>>>>>> Before 7u40, I think the code path got to the "else" branch of
>>>>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>>>>
>>>>>>> set_init_completed() is only called from Threads::create_vm() 
>>>>>>> and that
>>>>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by 
>>>>>>> default?
>>>>>>>
>>>>>>> Debugging with hs25, the set_init_completed() always happened 
>>>>>>> before
>>>>>>> create_class_path_entry() and both calls were done within the same
>>>>>>> thread - "vm startup".
>>>>>>>
>>>>>>> thanks,
>>>>>>> Calvin
>>>>>>>
>>>>>>>
>>>>>>> |
>>>>>>>> |||
>>>>>>>> ||
>>>>>>>> ||- Ioi
>>>>>>>> |
>>>>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>>>>> |I found an official version that's closest to the Redhat version
>>>>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>>>>> crashes.||
>>>>>>>>> ||
>>>>>>>>> ||sc11136754 ~$
>>>>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java 
>>>>>>>>> -showversion
>>>>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>> ||java version "1.6.0_25"||
>>>>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed 
>>>>>>>>> mode)||
>>>>>>>>> ||
>>>>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>>>>> ||#||
>>>>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>>>>> Environment:||
>>>>>>>>> ||#||
>>>>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>>>>> tid=140608485558016||
>>>>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>>>>> exceptions||
>>>>>>>>> ||#||
>>>>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed 
>>>>>>>>> mode
>>>>>>>>> linux-amd64 compressed oops)||
>>>>>>>>> ||# An error report file with more information is saved as:||
>>>>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>>>>> ||#||
>>>>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>>>>> ||#||
>>>>>>>>> ||Aborted (core dumped)||
>>>>>>>>> |
>>>>>>>>> - Ioi
>>>>>>>>>
>>>>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>>>>> apparently
>>>>>>>>>>> works differently
>>>>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed 
>>>>>>>>>>> this in
>>>>>>>>>>> their
>>>>>>>>>>> own repo??||
>>>>>>>>>>
>>>>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> ||
>>>>>>>>>>> |
>>>>>>>>>>> |==OEL6================================================
>>>>>>>>>>> ||
>>>>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue 
>>>>>>>>>>> Mar 6
>>>>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>>>>> ||sc11136754 ~$ java -showversion -cp . 
>>>>>>>>>>> -Xbootclasspath/a:foo.jar
>>>>>>>>>>> test2||
>>>>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>>>>> foo.jar||
>>>>>>>>>>> ||
>>>>>>>>>>> ==OFFICIAL============================================
>>>>>>>>>>> ||
>>>>>>>>>>> sc11136754 ~$ 
>>>>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>>>>> java version "1.6.0_22"
>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>>>>
>>>>>>>>>>> #
>>>>>>>>>>> # A fatal error has been detected by the Java Runtime 
>>>>>>>>>>> Environment:
>>>>>>>>>>> #
>>>>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>>>>> tid=140510319580928
>>>>>>>>>>> #  Error: ExceptionMark destructor expects no pending 
>>>>>>>>>>> exceptions
>>>>>>>>>>> #
>>>>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed 
>>>>>>>>>>> mode
>>>>>>>>>>> linux-amd64 )
>>>>>>>>>>> # An error report file with more information is saved as:
>>>>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>>>>> #
>>>>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>>>>> #
>>>>>>>>>>> |
>>>>>>>>>>> |======================================================
>>>>>>>>>>> ||
>>>>>>>>>>> ||- Ioi|
>>>>>>>>>>>
>>>>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>>>>> Hi Ioi, David,
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>>>>> files in
>>>>>>>>>>>>> the JDK:||
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||=========================||
>>>>>>>>>>>>> ||/*||
>>>>>>>>>>>>> ||javac test2.java||
>>>>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>>>> ||*/||
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||public class test2 {||
>>>>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>>>>> ||        try {||
>>>>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>>>>> ||        }||
>>>>>>>>>>>>> ||    }||
>>>>>>>>>>>>> ||}||
>>>>>>>>>>>>> ||=========================||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second 
>>>>>>>>>>>>> "java -cp .
>>>>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>>>>> |
>>>>>>>>>>>> |I saw crash with the latest 6 update release with both 
>>>>>>>>>>>> test cases.
>>>>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>>>>> |
>>>>>>>>>>>>> |||
>>>>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 
>>>>>>>>>>>>> behavior (not
>>>>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>>>>> checking),
>>>>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>>>>> |
>>>>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I 
>>>>>>>>>>>> changed look
>>>>>>>>>>>> the
>>>>>>>>>>>> same as jdk 8.
>>>>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>>>>> |
>>>>>>>>>>>>> |||
>>>>>>>>>>>>> ||Thanks||
>>>>>>>>>>>>> ||- Ioi||
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>>>>> |
>>>>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>>>>> exceptions. If exceptions can be posted then methods 
>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>>>>> CHECK_
>>>>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>>>>> expect any
>>>>>>>>>>>>>> exceptions to be possible. I would check with Karen on 
>>>>>>>>>>>>>> this. ||
>>>>>>>>>>>>>> |
>>>>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>>>>> changes.
>>>>>>>>>>>> I can give it a try.
>>>>>>>>>>>> |
>>>>>>>>>>>>>> || |
>>>>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>>>>> |
>>>>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>>>>> It won't be needed if the method is declared with TRAPS as 
>>>>>>>>>>>> the last
>>>>>>>>>>>> parameter (I think).
>>>>>>>>>>>>
>>>>>>>>>>>> thanks,
>>>>>>>>>>>> Calvin
>>>>>>>>>>>> |
>>>>>>>>>>>>>> || |
>>>>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior 
>>>>>>>>>>>>>> to throwing
>>>>>>>>>>>>>> exceptions - don't know what the thought process was 
>>>>>>>>>>>>>> there :) ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||David ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>> |Please review this small fix for fixing a fatal error 
>>>>>>>>>>>>>>> in ||
>>>>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException 
>>>>>>>>>>>>>>> in ||
>>>>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>>>>> similar
>>>>>>>>>>>>>>> crash ||
>>>>>>>>>>>>>>> ||by trying to load a class from an empty jar which is 
>>>>>>>>>>>>>>> in the ||
>>>>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>>>>> crash if
>>>>>>>>>>>>>>> the ||
>>>>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>>>>> || System.out.println("Class = " + cls.getName()); ||
>>>>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>>>>> ||} ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail 
>>>>>>>>>>>>>>> under the
>>>>>>>>>>>>>>> above test ||
>>>>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException 
>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>> thrown ||
>>>>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>>>>> ||         at 
>>>>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>>>>> Method) ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) 
>>>>>>>>>>>>>>> ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>>>>> ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> |
>>>>>>>>>>>>> |
>>>>>>>>>>>>> |
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>


From david.holmes at oracle.com  Wed Aug 21 22:21:16 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 22 Aug 2013 15:21:16 +1000
Subject: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on platforms
	if NMT detail is not supported
In-Reply-To: <52151121.1020906@oracle.com>
References: <5213C483.1060102@oracle.com> <5214173C.7000806@oracle.com>
	<52141C39.3070509@oracle.com> <52141E03.3060003@oracle.com>
	<52151121.1020906@oracle.com>
Message-ID: <52159FCC.1070304@oracle.com>

On 22/08/2013 5:12 AM, Chris Plummer wrote:
> New webrev posted. The only change from the previous one is dropping the
> Platform.java changes.
>
> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-04/

Looks fine to me - thanks.

Still need a second reviewer though. Christian?

David

> thanks,
>
> Chris
>
> On 8/20/13 6:55 PM, David Holmes wrote:
>> On 21/08/2013 11:47 AM, Chris Plummer wrote:
>>> On 8/20/13 6:26 PM, David Holmes wrote:
>>>> Hi Chris,
>>>>
>>>> On 21/08/2013 5:33 AM, Chris Plummer wrote:
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8020829
>>>>> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-03/
>>>>>
>>>>> On some platforms, NMT detail is not supported, and this was causing
>>>>> some jtreg tests to fail. These tests now query a new WhiteBox API to
>>>>> see if NMT detail is supported, and now behave properly if it is not
>>>>> supported.
>>>>
>>>> Okay.
>>>>
>>>>> I also fixed #ifdef INCLUDE_NMT in whitebox.cpp that should instead be
>>>>> #if INCLUDE_NMT. The source within the #if is now properly excluded
>>>>> from
>>>>> minimal VM builds.
>>>>
>>>> Okay.
>>>>
>>>>> The addition of Platform.isArm() is to support changes in closed
>>>>> source.
>>>>
>>>> I hate seeing these kinds of methods. Add a new platform, add a new
>>>> method - yuck! :(
>>>>
>>>> We could just use getOsArch().toLowerCase().startsWith("arm") directly.
>>>>
>>>> I'd even prefer to see:
>>>>
>>>> boolean isArch(String arch) {
>>>>   return osArch.toLowerCase().startsWith(arch.toLowerCase());
>>>> }
>>>>
>>>> and similarly for the OS - but that is going beyond this fix :)
>>> I'm not particularly tied to any specific way of doing this. I can do
>>> either of the above if you wish. Just let me know your preference.
>>
>> Drop isArm() please and change the closed usage to
>> getOsArch().toLowerCase().startsWith("arm").
>>
>> I'll file a RFE for Platform :)
>>
>> Thanks,
>> David
>>
>>> Chris
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Testing was done using the existing NMT tests, verifying that they now
>>>>> pass on platforms where NMT detail is not supported, and still pass on
>>>>> platforms where NMT detail is supported. A jprt job is currently in
>>>>> the
>>>>> queue to run all NMT jtreg tests on all platforms supported by jprt.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Chris Plummer
>>>
>

From calvin.cheung at oracle.com  Wed Aug 21 23:01:43 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Wed, 21 Aug 2013 23:01:43 -0700
Subject: RFR(S) 8020675: Trying to print to a pdf file with PDFill
	PDF&Image Writer 10.0 Build 4
In-Reply-To: <52158705.2080205@oracle.com>
References: <5202E595.3090608@oracle.com> <5202F8AA.3000105@oracle.com>
	<5202FF4C.3020705@oracle.com> <5203DEB1.9080808@oracle.com>
	<5203E8D7.107@oracle.com> <52040B08.8020401@oracle.com>
	<52040D1E.9000101@oracle.com> <520425BD.6090605@oracle.com>
	<52056910.8010005@oracle.com> <52087561.4000409@oracle.com>
	<5209D002.9090604@oracle.com> <52150BD6.2090408@oracle.com>
	<52152ABE.5000804@oracle.com> <521554EF.8030601@oracle.com>
	<52158705.2080205@oracle.com>
Message-ID: <5215A947.8060800@oracle.com>

Hi Ioi,

Thanks for your review.
I've made all the changes you've suggested including the later email 
about the 'const char* path' in ClassLoader::update_class_path_entry_list().
It's building fine and passed the unit test case.
I'll do more testing tomorrow before sending an updated webrev.

Calvin

On 8/21/2013 8:35 PM, Ioi Lam wrote:
> On 08/21/2013 05:01 PM, Calvin Cheung wrote:
>> On 8/21/2013 2:01 PM, Ioi Lam wrote:
>>> Calvin,
>>>
>>> I have not looked at the code in detail, but will your code now 
>>> repeatedly attempt to open the invalid JAR file? Maybe you can test 
>>> that by adding multiple Class.forName() calls in your tests (and 
>>> catching any exceptions).
>> public class test3 {
>>     public static void main(String[] args) {
>>         try {
>>             Class cls = Class.forName("xxx");
>>             System.out.println("Class = " + cls.getName());
>>             cls = Class.forName("yyy");
>>             System.out.println("Class = " + cls.getName());
>>         } catch (ClassNotFoundException cnfe) {
>>             cnfe.printStackTrace();
>>         }
>>     }
>> }
>>
> How about changing it to do this:
>
>      try {
>             Class.forName("xxx");
>       } catch (ClassNotFoundException cnfe) {
>             cnfe.printStackTrace();
>       }
>       try {
>             Class.forName("yyy");
>       } catch (ClassNotFoundException cnfe) {
>             cnfe.printStackTrace();
>       }
>
> I think you will find that create_class_path_entry will be called 
> twice for the invalid JAR file with lazy==false.
>
>> With the above test case, CNFE will be thrown for xxx and it won't 
>> try to load yyy.
>>>
>>> This is an error case (having an invalid JAR file in bootclasspath) 
>>> so performance is not important. However, if there's a simple way to 
>>> remember the result and never open the JAR file again that would be 
>>> ideal.
>> There's the following method in ClassLoader:
>> void ClassLoader::update_class_path_entry_list(const char *path,
>>                                                bool 
>> check_for_duplicates) {
>>   struct stat st;
>>   if (os::stat((char *)path, &st) == 0) {
>>     // File or directory found
>>     ClassPathEntry* new_entry = NULL;
>>     Thread* THREAD = Thread::current();
>>     create_class_path_entry((char *)path, st, &new_entry, 
>> LazyBootClassLoader, CHECK);
>>     // The kernel VM adds dynamically to the end of the classloader 
>> path and
>>     // doesn't reorder the bootclasspath which would break 
>> java.lang.Package
>>     // (see PackageInfo).
>>     // Add new entry to linked list
>>     if (!check_for_duplicates || !contains_entry(new_entry)) {
>>       add_to_list(new_entry);
>>     }
>>   }
>> }
>>
>> With my fix, if create_class_path_entry() fails, it'll return without 
>> calling add_to_list().
>
> I think you should do this to avoid the repeated opening of the 
> invalid JAR file:
>
> 317 ClassFileStream* LazyClassPathEntry::open_stream(const char* name) {
>  318   if (_meta_index != NULL &&
>  319       !_meta_index->may_contain(name)) {
>  320     return NULL;
>  321   }
>        if (_has_error) { // add a new field bool 
> LazyClassPathEntry::_has_error;
>          return NULL;
>        }
>  322   ClassPathEntry* cpe = resolve_entry();
>        if (cpe == NULL) {
>          _has_error = true;
>          return NULL;
>        } else {
>          return cpe->open_stream(name);
>  324 }
>
> Also, since you're changing the signature of 
> ClassLoader::create_class_path_entry(),
> I think you can perform onemore clean up:
>
> void ClassLoader::create_class_path_entry(char *path, const struct 
> stat* st, ClassPathEntry **new_entry, bool lazy, TRAPS)
>
> =>
>
> ClassPathEntry* ClassLoader::create_class_path_entry(char *path, 
> struct stat st, bool lazy, TRAPS)
>
> It just doesn't make sense to return void and set the returned value 
> in a pointer ...
>
> Also, the st structure is pretty big (88 bytes on linux 32 bits, 144 
> bytes on 64 bits). It's better to use a pointer. You can declare it 
> const to make sure that the callee doesn't modify it.
>
>
> Thanks
> - Ioi
>
>>
>> thanks,
>> Calvin
>>
>>>
>>> Thanks
>>> - Ioi
>>>
>>> On 08/21/2013 11:49 AM, Calvin Cheung wrote:
>>>> Can someone review this?
>>>>
>>>> Latest version:
>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>
>>>> Previous version without using TRAPS:
>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>>>>
>>>> thanks,
>>>> Calvin
>>>>
>>>> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>>>>> Hi David,
>>>>>
>>>>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>>>>> bit more and found that the error was thrown at a very early stage 
>>>>> within the init_globals() called from create_vm(). Below is the 
>>>>> call stack:
>>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, 
>>>>> stat st, ClassPathEntry * * new_entry, bool lazy) Line 508 C++
>>>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>>>> bytes    C++
>>>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) 
>>>>> Line 322 + 0x8 bytes C++
>>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>>> class_name, Handle class_loader, Thread * __the_thread__) Line 
>>>>> 1362 + 0x14 bytes    C++
>>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * 
>>>>> class_name, Handle class_loader, Handle protection_domain, Thread 
>>>>> * __the_thread__)  Line 206 + 0x15 bytes    C++
>>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * 
>>>>> class_name, Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>>>>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
>>>>> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd 
>>>>> bytes    C++
>>>>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>>>>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>>>>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>>>>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>>>>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>>>>      jvm.dll!SystemDictionary::initialize(Thread * 
>>>>> __the_thread__)  Line 1904 + 0x9 bytes    C++
>>>>>      jvm.dll!Universe::genesis(Thread * __the_thread__) Line 353 + 
>>>>> 0x9 bytes    C++
>>>>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes C++
>>>>> >   jvm.dll!init_globals()  Line 114    C++
>>>>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>>>>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>>>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void 
>>>>> * args)  Line 5133 + 0xd bytes    C++
>>>>>      java.exe!011013bd()
>>>>>      [Frames below may be incorrect and/or missing, no symbols 
>>>>> loaded for java.exe]
>>>>>      java.exe!01101e2f()
>>>>>      java.exe!0110c807()
>>>>>      java.exe!0110a5a1()
>>>>>      java.exe!0110c845()
>>>>>      java.exe!0110a62b()
>>>>>      kernel32.dll!767633aa()
>>>>>      ntdll.dll!77739ef2()
>>>>>      ntdll.dll!77739ec5()
>>>>>
>>>>> The error was thrown in the method below:
>>>>> bool Exceptions::special_exception(Thread* thread, const char* 
>>>>> file, int line, Symbol* h_name, const char* message) {
>>>>>   // bootstrapping check
>>>>>   if (!Universe::is_fully_initialized()) {
>>>>>     if (h_name == NULL) {
>>>>>       // atleast an informative message.
>>>>>       vm_exit_during_initialization("Exception", message);
>>>>>     } else {
>>>>>       vm_exit_during_initialization(h_name, 
>>>>> message);               <=====here
>>>>>     }
>>>>>     ShouldNotReachHere();
>>>>>   }
>>>>> }
>>>>>
>>>>> Note that it happened in the early stage during create_vm(), so 
>>>>> the (!Universe::is_fully_initialized()) was true.
>>>>>
>>>>> The class it was trying to load was sun/misc/AtomicLongCSImpl 
>>>>> which I couldn't find in 7u25.
>>>>> It was going through all the jar files in the bootclasspath and 
>>>>> finally got to the foo.jar which has 0-byte and got "error in 
>>>>> opening jar file" and then THROW_MSG().
>>>>> So I think it's just a coincident in 7u25 where the correct error 
>>>>> was thrown.
>>>>>
>>>>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>>>>> and thus it didn't hit the "error in opening jar file" (for the 
>>>>> foo.jar) early until it passed the point when the vm is considered 
>>>>> "initialized" - is_init_completed() is true. So when THROW_MSG() 
>>>>> was called when it tried to load the class specified by the test 
>>>>> case ("xxx"), it triggered the fatal error in ~ExceptionMark(). 
>>>>> Call stack up to the THROWN_MSG() as follows:
>>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, 
>>>>> stat st, ClassPathEntry * * new_entry, bool lazy) Line 508 C++
>>>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>>>> bytes    C++
>>>>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  
>>>>> Line 322 + 0x8 bytes    C++
>>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>>> __the_thread__)  Line 900 + 0x17 bytes C++
>>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>>> class_name, Handle class_loader, Thread * __the_thread__) Line 
>>>>> 1301 + 0x14 bytes    C++
>>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * 
>>>>> class_name, Handle class_loader, Handle protection_domain, Thread 
>>>>> * __the_thread__)  Line 232 + 0x15 bytes    C++
>>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * 
>>>>> class_name, Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>>>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char 
>>>>> * name)  Line 773 + 0x12 bytes    C++
>>>>>      java.dll!69461e8c()
>>>>>      [Frames below may be incorrect and/or missing, no symbols 
>>>>> loaded for java.dll]
>>>>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>>>>> elem)  Line 207 C++
>>>>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>>>>> Line 375 + 0x11 bytes    C++
>>>>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * 
>>>>> thread)  Line 40 + 0x9 bytes    C++
>>>>>
>>>>> I'll try using TRAPS all the way through the call chain probably 
>>>>> starting from ClassLoader::load_classfile().
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>>>>> Hi Calvin,
>>>>>>
>>>>>> I don't think this works. As I said previously the expectations 
>>>>>> of this code with regard to Java exceptions seems to be that it 
>>>>>> doesn't expect them at all. If you are using TRAPS etc then it 
>>>>>> should be used all the way through the call chain. What we have 
>>>>>> now is this call sequence:
>>>>>>
>>>>>> void ClassLoader::initialize() {
>>>>>>   assert(_package_hash_table == NULL, "should have been 
>>>>>> initialized by now.");
>>>>>>   EXCEPTION_MARK;
>>>>>>   ...
>>>>>>   setup_bootstrap_search_path();
>>>>>>     -> update_class_path_entry_list(path, false);
>>>>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>>>>> LazyBootClassLoader, CHECK);
>>>>>>
>>>>>> So if we return after the call to create_class_path_entry with an 
>>>>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>>>>
>>>>>> It may be that the EXCEPTION_MARK needs replacing with an 
>>>>>> explicit exception check and a vm_exit_during_initialization, if 
>>>>>> this exception can readily occur at runtime. But further analysis 
>>>>>> of all this code needs to be undertaken.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>>>>> I've updated the webrev with 2 changes:
>>>>>>> 1) added the TRAPS as the last parameter to the
>>>>>>> create_class_path_entry() method;
>>>>>>> 2) added a jtreg test case.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>>>
>>>>>>> Please take a look again.
>>>>>>>
>>>>>>> One more response in-lined below...
>>>>>>>
>>>>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>>>>> |I found one version of JDK7 that does not crash:||
>>>>>>>> ||
>>>>>>>> sc11136754 ~$
>>>>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>>>>
>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>> Error occurred during initialization of VM
>>>>>>>> java/lang/ClassNotFoundException: error in opening JAR file 
>>>>>>>> foo.jar
>>>>>>>> |
>>>>>>>
>>>>>>> |I noticed that it started breaking in 7u40 b01; it was still 
>>>>>>> working
>>>>>>> with 7u25.
>>>>>>> It may have something to do with when the set_init_completed() 
>>>>>>> is called:
>>>>>>> ExceptionMark::~ExceptionMark() {
>>>>>>>    if (_thread->has_pending_exception()) {
>>>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>>>      _thread->clear_pending_exception(); // Needed to avoid 
>>>>>>> infinite
>>>>>>> recursion
>>>>>>>      if (is_init_completed()) {
>>>>>>>        exception->print();
>>>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>>>> exceptions");
>>>>>>>      } else {
>>>>>>>        vm_exit_during_initialization(exception);
>>>>>>>      }
>>>>>>>    }
>>>>>>> }
>>>>>>>
>>>>>>> Before 7u40, I think the code path got to the "else" branch of
>>>>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>>>>
>>>>>>> set_init_completed() is only called from Threads::create_vm() 
>>>>>>> and that
>>>>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by 
>>>>>>> default?
>>>>>>>
>>>>>>> Debugging with hs25, the set_init_completed() always happened 
>>>>>>> before
>>>>>>> create_class_path_entry() and both calls were done within the same
>>>>>>> thread - "vm startup".
>>>>>>>
>>>>>>> thanks,
>>>>>>> Calvin
>>>>>>>
>>>>>>>
>>>>>>> |
>>>>>>>> |||
>>>>>>>> ||
>>>>>>>> ||- Ioi
>>>>>>>> |
>>>>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>>>>> |I found an official version that's closest to the Redhat version
>>>>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>>>>> crashes.||
>>>>>>>>> ||
>>>>>>>>> ||sc11136754 ~$
>>>>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java 
>>>>>>>>> -showversion
>>>>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>> ||java version "1.6.0_25"||
>>>>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed 
>>>>>>>>> mode)||
>>>>>>>>> ||
>>>>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>>>>> ||#||
>>>>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>>>>> Environment:||
>>>>>>>>> ||#||
>>>>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>>>>> tid=140608485558016||
>>>>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>>>>> exceptions||
>>>>>>>>> ||#||
>>>>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed 
>>>>>>>>> mode
>>>>>>>>> linux-amd64 compressed oops)||
>>>>>>>>> ||# An error report file with more information is saved as:||
>>>>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>>>>> ||#||
>>>>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>>>>> ||#||
>>>>>>>>> ||Aborted (core dumped)||
>>>>>>>>> |
>>>>>>>>> - Ioi
>>>>>>>>>
>>>>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>>>>> apparently
>>>>>>>>>>> works differently
>>>>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed 
>>>>>>>>>>> this in
>>>>>>>>>>> their
>>>>>>>>>>> own repo??||
>>>>>>>>>>
>>>>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> ||
>>>>>>>>>>> |
>>>>>>>>>>> |==OEL6================================================
>>>>>>>>>>> ||
>>>>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue 
>>>>>>>>>>> Mar 6
>>>>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>>>>> ||sc11136754 ~$ java -showversion -cp . 
>>>>>>>>>>> -Xbootclasspath/a:foo.jar
>>>>>>>>>>> test2||
>>>>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>>>>> foo.jar||
>>>>>>>>>>> ||
>>>>>>>>>>> ==OFFICIAL============================================
>>>>>>>>>>> ||
>>>>>>>>>>> sc11136754 ~$ 
>>>>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>>>>> java version "1.6.0_22"
>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>>>>
>>>>>>>>>>> #
>>>>>>>>>>> # A fatal error has been detected by the Java Runtime 
>>>>>>>>>>> Environment:
>>>>>>>>>>> #
>>>>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>>>>> tid=140510319580928
>>>>>>>>>>> #  Error: ExceptionMark destructor expects no pending 
>>>>>>>>>>> exceptions
>>>>>>>>>>> #
>>>>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed 
>>>>>>>>>>> mode
>>>>>>>>>>> linux-amd64 )
>>>>>>>>>>> # An error report file with more information is saved as:
>>>>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>>>>> #
>>>>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>>>>> #
>>>>>>>>>>> |
>>>>>>>>>>> |======================================================
>>>>>>>>>>> ||
>>>>>>>>>>> ||- Ioi|
>>>>>>>>>>>
>>>>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>>>>> Hi Ioi, David,
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>>>>> files in
>>>>>>>>>>>>> the JDK:||
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||=========================||
>>>>>>>>>>>>> ||/*||
>>>>>>>>>>>>> ||javac test2.java||
>>>>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>>>> ||*/||
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||public class test2 {||
>>>>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>>>>> ||        try {||
>>>>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>>>>> ||        }||
>>>>>>>>>>>>> ||    }||
>>>>>>>>>>>>> ||}||
>>>>>>>>>>>>> ||=========================||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second 
>>>>>>>>>>>>> "java -cp .
>>>>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>>>>> |
>>>>>>>>>>>> |I saw crash with the latest 6 update release with both 
>>>>>>>>>>>> test cases.
>>>>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>>>>> |
>>>>>>>>>>>>> |||
>>>>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 
>>>>>>>>>>>>> behavior (not
>>>>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>>>>> checking),
>>>>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>>>>> |
>>>>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I 
>>>>>>>>>>>> changed look
>>>>>>>>>>>> the
>>>>>>>>>>>> same as jdk 8.
>>>>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>>>>> |
>>>>>>>>>>>>> |||
>>>>>>>>>>>>> ||Thanks||
>>>>>>>>>>>>> ||- Ioi||
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>>>>> |
>>>>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>>>>> exceptions. If exceptions can be posted then methods 
>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>>>>> CHECK_
>>>>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>>>>> expect any
>>>>>>>>>>>>>> exceptions to be possible. I would check with Karen on 
>>>>>>>>>>>>>> this. ||
>>>>>>>>>>>>>> |
>>>>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>>>>> changes.
>>>>>>>>>>>> I can give it a try.
>>>>>>>>>>>> |
>>>>>>>>>>>>>> || |
>>>>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>>>>> |
>>>>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>>>>> It won't be needed if the method is declared with TRAPS as 
>>>>>>>>>>>> the last
>>>>>>>>>>>> parameter (I think).
>>>>>>>>>>>>
>>>>>>>>>>>> thanks,
>>>>>>>>>>>> Calvin
>>>>>>>>>>>> |
>>>>>>>>>>>>>> || |
>>>>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior 
>>>>>>>>>>>>>> to throwing
>>>>>>>>>>>>>> exceptions - don't know what the thought process was 
>>>>>>>>>>>>>> there :) ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||David ||
>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>> |Please review this small fix for fixing a fatal error 
>>>>>>>>>>>>>>> in ||
>>>>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException 
>>>>>>>>>>>>>>> in ||
>>>>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>>>>> similar
>>>>>>>>>>>>>>> crash ||
>>>>>>>>>>>>>>> ||by trying to load a class from an empty jar which is 
>>>>>>>>>>>>>>> in the ||
>>>>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>>>>> crash if
>>>>>>>>>>>>>>> the ||
>>>>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>>>>> || System.out.println("Class = " + cls.getName()); ||
>>>>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>>>>> ||} ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail 
>>>>>>>>>>>>>>> under the
>>>>>>>>>>>>>>> above test ||
>>>>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException 
>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>> thrown ||
>>>>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>>>>> ||         at 
>>>>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>>>>> Method) ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) 
>>>>>>>>>>>>>>> ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>>>>> ||
>>>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> |
>>>>>>>>>>>>> |
>>>>>>>>>>>>> |
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>


From staffan.larsen at oracle.com  Thu Aug 22 04:09:48 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 22 Aug 2013 13:09:48 +0200
Subject: Request for review:8021948:Change
	InstanceKlass::_source_file_name and _generic_signature from
	Symbol* to constant pool index
In-Reply-To: <52094970.1030206@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
Message-ID: <4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>

This changed caused com/sun/jdi/RedefineMulti.sh to fail. See JDK-8023547. I'm looking at it, but if someone sees the problem, let me know.

/Staffan

On 12 aug 2013, at 22:45, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:

> Hi Ioi,
> 
> Thanks for the review! I'll try those tests also.
> 
> Thanks,
> Jiangli
> 
> On 08/12/2013 11:09 AM, Ioi Lam wrote:
>> Looks good.
>> 
>> Since you're touching the class loader code, maybe you should run vm.parallel_class_loading.testlist as well.
>> 
>> Thanks
>> - Ioi
>> 
>> On 08/09/2013 02:22 PM, Jiangli Zhou wrote:
>>> Hi,
>>> 
>>> Could anyone help me review this?
>>> 
>>> Thanks,
>>> Jiangli
>>> 
>>> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>>>> Hi,
>>>> 
>>>> Please review following change for JDK-8021948:
>>>> 
>>>>   http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>>> 
>>>> Both InstanceKlass::_source_file_name and InstanceKlass::_generic_signature were pointers to Symbol. They are now indexes to constant pool entries. Both fields are now u2 type, and co-located with other non-pointer type fields for more efficient alignment on 64-bit machine. On 32-bit machine, the change saves 4bytes for each class.
>>>> 
>>>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, nsk.stress.testlist and nsk.jvmti.testlist.
>>>> 
>>>> Thanks,
>>>> Jiangli
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/6150b6f1/attachment-0001.html 

From staffan.larsen at oracle.com  Thu Aug 22 05:54:48 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 22 Aug 2013 14:54:48 +0200
Subject: Request for review:8021948:Change
	InstanceKlass::_source_file_name and _generic_signature from
	Symbol* to constant pool index
In-Reply-To: <4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
Message-ID: <0F3DB9FD-1630-4ECE-818C-26D2A4B3953C@oracle.com>

I don't claim to understand this, but if I remove the changes to jvmtiRedefineClasses.cpp in [1] the test passes. My guess is that there is no need to change the source file name cp index in scratch_class since there is no merge happening for that attribute, whatever index it has in the new class is the correct one.

Thoughts?

/Staffan

[1] http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e22ee8e7ae62


On 22 aug 2013, at 13:09, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> This changed caused com/sun/jdi/RedefineMulti.sh to fail. See JDK-8023547. I'm looking at it, but if someone sees the problem, let me know.
> 
> /Staffan
> 
> On 12 aug 2013, at 22:45, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
> 
>> Hi Ioi,
>> 
>> Thanks for the review! I'll try those tests also.
>> 
>> Thanks,
>> Jiangli
>> 
>> On 08/12/2013 11:09 AM, Ioi Lam wrote:
>>> Looks good.
>>> 
>>> Since you're touching the class loader code, maybe you should run vm.parallel_class_loading.testlist as well.
>>> 
>>> Thanks
>>> - Ioi
>>> 
>>> On 08/09/2013 02:22 PM, Jiangli Zhou wrote:
>>>> Hi,
>>>> 
>>>> Could anyone help me review this?
>>>> 
>>>> Thanks,
>>>> Jiangli
>>>> 
>>>> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>>>>> Hi,
>>>>> 
>>>>> Please review following change for JDK-8021948:
>>>>> 
>>>>>   http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>>>> 
>>>>> Both InstanceKlass::_source_file_name and InstanceKlass::_generic_signature were pointers to Symbol. They are now indexes to constant pool entries. Both fields are now u2 type, and co-located with other non-pointer type fields for more efficient alignment on 64-bit machine. On 32-bit machine, the change saves 4bytes for each class.
>>>>> 
>>>>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, nsk.stress.testlist and nsk.jvmti.testlist.
>>>>> 
>>>>> Thanks,
>>>>> Jiangli
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/3417fdea/attachment.html 

From harold.seigel at oracle.com  Thu Aug 22 05:59:03 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 22 Aug 2013 08:59:03 -0400
Subject: RFR 8022183: GCC 4.56 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <52158338.8020003@oracle.com>
References: <52152EE3.2040804@oracle.com> <52158338.8020003@oracle.com>
Message-ID: <52160B17.2010602@oracle.com>

Hi David,

Thanks for your comments.  I was hoping to limit the impact of my 
change.  So, I only modified i486.make.  I'll look into moving the 
change to gcc.make and see if it impacts clang.

Thanks, Harold

On 8/21/2013 11:19 PM, David Holmes wrote:
> Hi Harold,
>
> I know you modelled this on the code in amd64.make but it really seems 
> to me that this belongs in gcc.make. Note that gcc.make already 
> contains related flags for clang:
>
> ifeq ($(USE_CLANG), true)
>   # Before Clang 3.1, we had to pass the stack alignment specification 
> directly to llvm with the help of '-mllvm'
>   # Starting with version 3.1, Clang understands the 
> '-mstack-alignment' (and rejects '-mllvm -stack-alignment')
>   ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 3 \) \| \( \( 
> $(CC_VER_MAJOR) = 3 \) \& \( $(CC_VER_MINOR) \>= 1 \) \))" "0"
>     STACK_ALIGNMENT_OPT = -mno-omit-leaf-frame-pointer 
> -mstack-alignment=16
>   else
>     STACK_ALIGNMENT_OPT = -mno-omit-leaf-frame-pointer -mllvm 
> -stack-alignment=16
>   endif
> endif
>
> If placed in gcc.make the code in amd64.make could be removed.
>
> Hmmm, it also seems to me that this change will also add the flag for 
> clang (as does the existing amd5=64 code). I'm unsure if that is good 
> or bad? Maybe one of our clang experts could chime in if they are on 
> this list.
>
> Thanks,
> David
>
> On 22/08/2013 7:19 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this small fix for bug 8022183.  This fix is needed in
>> order to build hotspot on 32-bit Linux with newer versions of gcc. The
>> fix explicitly specifies "-fno-omit-frame-pointer" in the makefile for
>> 32-bit Linux.
>>
>> The fix was tested using NMT with -version and with GCBasher.
>>
>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>>
>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>>
>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>>
>> Thanks, Harold


From karen.kinnear at oracle.com  Thu Aug 22 06:31:09 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 22 Aug 2013 09:31:09 -0400
Subject: S RFR: 8012294: remove generic default handling
Message-ID: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>

Please review:

webrev:  http://cr.openjdk.java.net/~acorn/8012294/webrev/
http://bugs.sun.com/view_bug.do?bug_id=8012294

This is a cleanup bug - fix 8013635 removed generic signature support from the vm
default method handling, but as a temporary fallback, put this under the develop flag
ParseGenericDefaults. This has been shaken out sufficiently that the old code under
that flag can now be removed, including ParseGenericDefaults and ParseAllGenericSignatures,
both of which were temporary develop flags for early lambda default method handling.

tests:
java -XX:+ParseGenericDefaults -XX:+CompileTheWorld -Xbootclasspath/p:<mypath>db.jar - fails before change
java -XX:+ParseGenericDefaults - won't start VM after change
java -XX:+ParseAllGenericSignatures - won't start VM after change
jprt
defmeth tests (no new failures)
vm.quick.testlist in progress

thanks,
Karen




From coleen.phillimore at oracle.com  Thu Aug 22 07:08:48 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 22 Aug 2013 10:08:48 -0400
Subject: RFR 8022183: GCC 4.56 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <52153ECD.9030006@oracle.com>
References: <52152EE3.2040804@oracle.com> <52153ECD.9030006@oracle.com>
Message-ID: <52161B70.3090907@oracle.com>


Harold,

Regarding the comment, isn't it not just the serviceability agent but 
the stack trace in hs_err and the stack walking in NMT.   Isn't it 
generally "Stack walking in the JVM relies on frame pointer..."

thanks,
Coleen

On 08/21/2013 06:27 PM, Daniel D. Daugherty wrote:
> On 8/21/13 3:19 PM, harold seigel wrote:
>> Hi,
>>
>> Please review this small fix for bug 8022183.  This fix is needed in 
>> order to build hotspot on 32-bit Linux with newer versions of gcc. 
>> The fix explicitly specifies "-fno-omit-frame-pointer" in the 
>> makefile for 32-bit Linux.
>>
>> The fix was tested using NMT with -version and with GCBasher.
>>
>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/ 
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>
> make/linux/makefiles/i486.make
>     No comments.
>
> Thumbs up!
>
> Dan
>
>
>>
>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>>
>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>>
>> Thanks, Harold
>


From coleen.phillimore at oracle.com  Thu Aug 22 07:30:54 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 22 Aug 2013 10:30:54 -0400
Subject: RFR (S): JDK-8020829: JT_HS: 2 runtime NMT tests fail on platforms
	if NMT detail is not supported
In-Reply-To: <52159FCC.1070304@oracle.com>
References: <5213C483.1060102@oracle.com> <5214173C.7000806@oracle.com>
	<52141C39.3070509@oracle.com> <52141E03.3060003@oracle.com>
	<52151121.1020906@oracle.com> <52159FCC.1070304@oracle.com>
Message-ID: <5216209E.4050802@oracle.com>


Christian's on a plane.  This code looks fine.
Coleen

On 08/22/2013 01:21 AM, David Holmes wrote:
> On 22/08/2013 5:12 AM, Chris Plummer wrote:
>> New webrev posted. The only change from the previous one is dropping the
>> Platform.java changes.
>>
>> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-04/
>
> Looks fine to me - thanks.
>
> Still need a second reviewer though. Christian?
>
> David
>
>> thanks,
>>
>> Chris
>>
>> On 8/20/13 6:55 PM, David Holmes wrote:
>>> On 21/08/2013 11:47 AM, Chris Plummer wrote:
>>>> On 8/20/13 6:26 PM, David Holmes wrote:
>>>>> Hi Chris,
>>>>>
>>>>> On 21/08/2013 5:33 AM, Chris Plummer wrote:
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8020829
>>>>>> http://cr.openjdk.java.net/~cjplummer/8020829/webrev-03/
>>>>>>
>>>>>> On some platforms, NMT detail is not supported, and this was causing
>>>>>> some jtreg tests to fail. These tests now query a new WhiteBox 
>>>>>> API to
>>>>>> see if NMT detail is supported, and now behave properly if it is not
>>>>>> supported.
>>>>>
>>>>> Okay.
>>>>>
>>>>>> I also fixed #ifdef INCLUDE_NMT in whitebox.cpp that should 
>>>>>> instead be
>>>>>> #if INCLUDE_NMT. The source within the #if is now properly excluded
>>>>>> from
>>>>>> minimal VM builds.
>>>>>
>>>>> Okay.
>>>>>
>>>>>> The addition of Platform.isArm() is to support changes in closed
>>>>>> source.
>>>>>
>>>>> I hate seeing these kinds of methods. Add a new platform, add a new
>>>>> method - yuck! :(
>>>>>
>>>>> We could just use getOsArch().toLowerCase().startsWith("arm") 
>>>>> directly.
>>>>>
>>>>> I'd even prefer to see:
>>>>>
>>>>> boolean isArch(String arch) {
>>>>>   return osArch.toLowerCase().startsWith(arch.toLowerCase());
>>>>> }
>>>>>
>>>>> and similarly for the OS - but that is going beyond this fix :)
>>>> I'm not particularly tied to any specific way of doing this. I can do
>>>> either of the above if you wish. Just let me know your preference.
>>>
>>> Drop isArm() please and change the closed usage to
>>> getOsArch().toLowerCase().startsWith("arm").
>>>
>>> I'll file a RFE for Platform :)
>>>
>>> Thanks,
>>> David
>>>
>>>> Chris
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Testing was done using the existing NMT tests, verifying that 
>>>>>> they now
>>>>>> pass on platforms where NMT detail is not supported, and still 
>>>>>> pass on
>>>>>> platforms where NMT detail is supported. A jprt job is currently in
>>>>>> the
>>>>>> queue to run all NMT jtreg tests on all platforms supported by jprt.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Chris Plummer
>>>>
>>


From harold.seigel at oracle.com  Thu Aug 22 07:37:29 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 22 Aug 2013 10:37:29 -0400
Subject: RFR 8022183: GCC 4.6 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <52161B70.3090907@oracle.com>
References: <52152EE3.2040804@oracle.com> <52153ECD.9030006@oracle.com>
	<52161B70.3090907@oracle.com>
Message-ID: <52162229.6070803@oracle.com>

Yes, I'll update the comment.

Thanks, Harold

On 8/22/2013 10:08 AM, Coleen Phillimore wrote:
>
> Harold,
>
> Regarding the comment, isn't it not just the serviceability agent but 
> the stack trace in hs_err and the stack walking in NMT. Isn't it 
> generally "Stack walking in the JVM relies on frame pointer..."
>
> thanks,
> Coleen
>
> On 08/21/2013 06:27 PM, Daniel D. Daugherty wrote:
>> On 8/21/13 3:19 PM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this small fix for bug 8022183.  This fix is needed in 
>>> order to build hotspot on 32-bit Linux with newer versions of gcc. 
>>> The fix explicitly specifies "-fno-omit-frame-pointer" in the 
>>> makefile for 32-bit Linux.
>>>
>>> The fix was tested using NMT with -version and with GCBasher.
>>>
>>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/ 
>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>>
>> make/linux/makefiles/i486.make
>>     No comments.
>>
>> Thumbs up!
>>
>> Dan
>>
>>
>>>
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>>>
>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>>>
>>> Thanks, Harold
>>
>


From harold.seigel at oracle.com  Thu Aug 22 08:00:10 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 22 Aug 2013 11:00:10 -0400
Subject: RFR 8022183: GCC 4.6 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <52162229.6070803@oracle.com>
References: <52152EE3.2040804@oracle.com> <52153ECD.9030006@oracle.com>
	<52161B70.3090907@oracle.com> <52162229.6070803@oracle.com>
Message-ID: <5216277A.7090205@oracle.com>

Please review this updated webrev for bug 8022183: 
http://cr.openjdk.java.net/~hseigel/bug_8022183.2/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_8022183.2/>

This change updates the comment and moves the "-fno-omit-frame-pointer" 
option to gcc.make.  This change was tested on both 32 and 64 bit Linux 
builds using NMT and GCBasher. Also, the build log was inspected to make 
sure that "-fno-omit-frame-pointer" was specified during the C++ compiles.

I verified that Clang also accepts the "-fno-omit-frame-pointer" option.

Thanks, Harold


On 8/22/2013 10:37 AM, harold seigel wrote:
> Yes, I'll update the comment.
>
> Thanks, Harold
>
> On 8/22/2013 10:08 AM, Coleen Phillimore wrote:
>>
>> Harold,
>>
>> Regarding the comment, isn't it not just the serviceability agent but 
>> the stack trace in hs_err and the stack walking in NMT. Isn't it 
>> generally "Stack walking in the JVM relies on frame pointer..."
>>
>> thanks,
>> Coleen
>>
>> On 08/21/2013 06:27 PM, Daniel D. Daugherty wrote:
>>> On 8/21/13 3:19 PM, harold seigel wrote:
>>>> Hi,
>>>>
>>>> Please review this small fix for bug 8022183.  This fix is needed 
>>>> in order to build hotspot on 32-bit Linux with newer versions of 
>>>> gcc. The fix explicitly specifies "-fno-omit-frame-pointer" in the 
>>>> makefile for 32-bit Linux.
>>>>
>>>> The fix was tested using NMT with -version and with GCBasher.
>>>>
>>>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/ 
>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>>>
>>> make/linux/makefiles/i486.make
>>>     No comments.
>>>
>>> Thumbs up!
>>>
>>> Dan
>>>
>>>
>>>>
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>>>>
>>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>>>>
>>>> Thanks, Harold
>>>
>>
>


From coleen.phillimore at oracle.com  Thu Aug 22 07:57:30 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 22 Aug 2013 10:57:30 -0400
Subject: RFR 8022183: GCC 4.6 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <5216277A.7090205@oracle.com>
References: <52152EE3.2040804@oracle.com> <52153ECD.9030006@oracle.com>
	<52161B70.3090907@oracle.com> <52162229.6070803@oracle.com>
	<5216277A.7090205@oracle.com>
Message-ID: <521626DA.5080509@oracle.com>


Looks much better.
Thanks!
Coleen

On 08/22/2013 11:00 AM, harold seigel wrote:
> Please review this updated webrev for bug 8022183: 
> http://cr.openjdk.java.net/~hseigel/bug_8022183.2/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183.2/>
>
> This change updates the comment and moves the 
> "-fno-omit-frame-pointer" option to gcc.make.  This change was tested 
> on both 32 and 64 bit Linux builds using NMT and GCBasher. Also, the 
> build log was inspected to make sure that "-fno-omit-frame-pointer" 
> was specified during the C++ compiles.
>
> I verified that Clang also accepts the "-fno-omit-frame-pointer" option.
>
> Thanks, Harold
>
>
> On 8/22/2013 10:37 AM, harold seigel wrote:
>> Yes, I'll update the comment.
>>
>> Thanks, Harold
>>
>> On 8/22/2013 10:08 AM, Coleen Phillimore wrote:
>>>
>>> Harold,
>>>
>>> Regarding the comment, isn't it not just the serviceability agent 
>>> but the stack trace in hs_err and the stack walking in NMT. Isn't it 
>>> generally "Stack walking in the JVM relies on frame pointer..."
>>>
>>> thanks,
>>> Coleen
>>>
>>> On 08/21/2013 06:27 PM, Daniel D. Daugherty wrote:
>>>> On 8/21/13 3:19 PM, harold seigel wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this small fix for bug 8022183.  This fix is needed 
>>>>> in order to build hotspot on 32-bit Linux with newer versions of 
>>>>> gcc. The fix explicitly specifies "-fno-omit-frame-pointer" in the 
>>>>> makefile for 32-bit Linux.
>>>>>
>>>>> The fix was tested using NMT with -version and with GCBasher.
>>>>>
>>>>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/ 
>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>>>>
>>>> make/linux/makefiles/i486.make
>>>>     No comments.
>>>>
>>>> Thumbs up!
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>>>>>
>>>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>>>>>
>>>>> Thanks, Harold
>>>>
>>>
>>
>


From daniel.daugherty at oracle.com  Thu Aug 22 08:20:59 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 22 Aug 2013 09:20:59 -0600
Subject: RFR 8022183: GCC 4.6 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <5216277A.7090205@oracle.com>
References: <52152EE3.2040804@oracle.com> <52153ECD.9030006@oracle.com>
	<52161B70.3090907@oracle.com> <52162229.6070803@oracle.com>
	<5216277A.7090205@oracle.com>
Message-ID: <52162C5B.4040904@oracle.com>


On 8/22/13 9:00 AM, harold seigel wrote:
> Please review this updated webrev for bug 8022183: 
> http://cr.openjdk.java.net/~hseigel/bug_8022183.2/ 
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183.2/>

make/linux/makefiles/amd64.make
     No comments.

make/linux/makefiles/gcc.make
     Definitely a better place to put the change.

Thumbs up.

Dan


>
> This change updates the comment and moves the 
> "-fno-omit-frame-pointer" option to gcc.make.  This change was tested 
> on both 32 and 64 bit Linux builds using NMT and GCBasher. Also, the 
> build log was inspected to make sure that "-fno-omit-frame-pointer" 
> was specified during the C++ compiles.
>
> I verified that Clang also accepts the "-fno-omit-frame-pointer" option.
>
> Thanks, Harold
>
>
> On 8/22/2013 10:37 AM, harold seigel wrote:
>> Yes, I'll update the comment.
>>
>> Thanks, Harold
>>
>> On 8/22/2013 10:08 AM, Coleen Phillimore wrote:
>>>
>>> Harold,
>>>
>>> Regarding the comment, isn't it not just the serviceability agent 
>>> but the stack trace in hs_err and the stack walking in NMT. Isn't it 
>>> generally "Stack walking in the JVM relies on frame pointer..."
>>>
>>> thanks,
>>> Coleen
>>>
>>> On 08/21/2013 06:27 PM, Daniel D. Daugherty wrote:
>>>> On 8/21/13 3:19 PM, harold seigel wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this small fix for bug 8022183.  This fix is needed 
>>>>> in order to build hotspot on 32-bit Linux with newer versions of 
>>>>> gcc. The fix explicitly specifies "-fno-omit-frame-pointer" in the 
>>>>> makefile for 32-bit Linux.
>>>>>
>>>>> The fix was tested using NMT with -version and with GCBasher.
>>>>>
>>>>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/ 
>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>>>>
>>>> make/linux/makefiles/i486.make
>>>>     No comments.
>>>>
>>>> Thumbs up!
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>>>>>
>>>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>>>>>
>>>>> Thanks, Harold
>>>>
>>>
>>
>


From serguei.spitsyn at oracle.com  Thu Aug 22 09:00:44 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 22 Aug 2013 09:00:44 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <0F3DB9FD-1630-4ECE-818C-26D2A4B3953C@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<0F3DB9FD-1630-4ECE-818C-26D2A4B3953C@oracle.com>
Message-ID: <521635AC.6050904@oracle.com>

I'm looking at it but it is time for a Town Hall meeting.

Thanks,
Serguei

On 8/22/13 5:54 AM, Staffan Larsen wrote:
> I don't claim to understand this, but if I remove the changes to 
> jvmtiRedefineClasses.cpp in [1] the test passes. My guess is that 
> there is no need to change the source file name cp index in 
> scratch_class since there is no merge happening for that attribute, 
> whatever index it has in the new class is the correct one.
>
> Thoughts?
>
> /Staffan
>
> [1] http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e22ee8e7ae62
>
>
> On 22 aug 2013, at 13:09, Staffan Larsen <staffan.larsen at oracle.com 
> <mailto:staffan.larsen at oracle.com>> wrote:
>
>> This changed caused com/sun/jdi/RedefineMulti.sh to fail. 
>> See JDK-8023547. I'm looking at it, but if someone sees the problem, 
>> let me know.
>>
>> /Staffan
>>
>> On 12 aug 2013, at 22:45, Jiangli Zhou <jiangli.zhou at oracle.com 
>> <mailto:jiangli.zhou at oracle.com>> wrote:
>>
>>> Hi Ioi,
>>>
>>> Thanks for the review! I'll try those tests also.
>>>
>>> Thanks,
>>> Jiangli
>>>
>>> On 08/12/2013 11:09 AM, Ioi Lam wrote:
>>>> Looks good.
>>>>
>>>> Since you're touching the class loader code, maybe you should run 
>>>> vm.parallel_class_loading.testlist as well.
>>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>> On 08/09/2013 02:22 PM, Jiangli Zhou wrote:
>>>>> Hi,
>>>>>
>>>>> Could anyone help me review this?
>>>>>
>>>>> Thanks,
>>>>> Jiangli
>>>>>
>>>>> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review following change for JDK-8021948 
>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>>>>>
>>>>>> Both InstanceKlass::_source_file_name and 
>>>>>> InstanceKlass::_generic_signature were pointers to Symbol. They 
>>>>>> are now indexes to constant pool entries. Both fields are now u2 
>>>>>> type, and co-located with other non-pointer type fields for more 
>>>>>> efficient alignment on 64-bit machine. On 32-bit machine, the 
>>>>>> change saves 4bytes for each class.
>>>>>>
>>>>>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>>>>>> nsk.stress.testlist and nsk.jvmti.testlist.
>>>>>>
>>>>>> Thanks,
>>>>>> Jiangli
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/c1101726/attachment.html 

From jiangli.zhou at oracle.com  Thu Aug 22 09:45:12 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 09:45:12 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
Message-ID: <52164018.8090200@oracle.com>

Hi Staffan,

Thanks for the heads up! I'll also take a look.

Jiangli

On 08/22/2013 04:09 AM, Staffan Larsen wrote:
> This changed caused com/sun/jdi/RedefineMulti.sh to fail. 
> See JDK-8023547. I'm looking at it, but if someone sees the problem, 
> let me know.
>
> /Staffan
>
> On 12 aug 2013, at 22:45, Jiangli Zhou <jiangli.zhou at oracle.com 
> <mailto:jiangli.zhou at oracle.com>> wrote:
>
>> Hi Ioi,
>>
>> Thanks for the review! I'll try those tests also.
>>
>> Thanks,
>> Jiangli
>>
>> On 08/12/2013 11:09 AM, Ioi Lam wrote:
>>> Looks good.
>>>
>>> Since you're touching the class loader code, maybe you should run 
>>> vm.parallel_class_loading.testlist as well.
>>>
>>> Thanks
>>> - Ioi
>>>
>>> On 08/09/2013 02:22 PM, Jiangli Zhou wrote:
>>>> Hi,
>>>>
>>>> Could anyone help me review this?
>>>>
>>>> Thanks,
>>>> Jiangli
>>>>
>>>> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>>>>> Hi,
>>>>>
>>>>> Please review following change for JDK-8021948 
>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>>>>
>>>>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>>>>
>>>>> Both InstanceKlass::_source_file_name and 
>>>>> InstanceKlass::_generic_signature were pointers to Symbol. They 
>>>>> are now indexes to constant pool entries. Both fields are now u2 
>>>>> type, and co-located with other non-pointer type fields for more 
>>>>> efficient alignment on 64-bit machine. On 32-bit machine, the 
>>>>> change saves 4bytes for each class.
>>>>>
>>>>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>>>>> nsk.stress.testlist and nsk.jvmti.testlist.
>>>>>
>>>>> Thanks,
>>>>> Jiangli
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/69123a02/attachment-0001.html 

From jiangli.zhou at oracle.com  Thu Aug 22 10:07:45 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 10:07:45 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <0F3DB9FD-1630-4ECE-818C-26D2A4B3953C@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<0F3DB9FD-1630-4ECE-818C-26D2A4B3953C@oracle.com>
Message-ID: <52164561.4040200@oracle.com>

Hi Staffan,

Thanks so much for looking into this.

On 08/22/2013 05:54 AM, Staffan Larsen wrote:
> I don't claim to understand this, but if I remove the changes to 
> jvmtiRedefineClasses.cpp in [1] the test passes. My guess is that 
> there is no need to change the source file name cp index in 
> scratch_class since there is no merge happening for that attribute, 
> whatever index it has in the new class is the correct one.

Initially I didn't have the source file name index rewrite part and ran 
into a crash with incorrect source file name index during testing. It 
was one of the jvmti tests, I think. I don't remember which test though. 
After class redefine and merge, the new class source file name index in 
the scratch_class was pointing to a incorrect entry. Adding the source 
file name index rewrite part resolved the crash for that test.

Thanks,
Jiangli

>
> Thoughts?
>
> /Staffan
>
> [1] http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e22ee8e7ae62
>
>
> On 22 aug 2013, at 13:09, Staffan Larsen <staffan.larsen at oracle.com 
> <mailto:staffan.larsen at oracle.com>> wrote:
>
>> This changed caused com/sun/jdi/RedefineMulti.sh to fail. 
>> See JDK-8023547. I'm looking at it, but if someone sees the problem, 
>> let me know.
>>
>> /Staffan
>>
>> On 12 aug 2013, at 22:45, Jiangli Zhou <jiangli.zhou at oracle.com 
>> <mailto:jiangli.zhou at oracle.com>> wrote:
>>
>>> Hi Ioi,
>>>
>>> Thanks for the review! I'll try those tests also.
>>>
>>> Thanks,
>>> Jiangli
>>>
>>> On 08/12/2013 11:09 AM, Ioi Lam wrote:
>>>> Looks good.
>>>>
>>>> Since you're touching the class loader code, maybe you should run 
>>>> vm.parallel_class_loading.testlist as well.
>>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>> On 08/09/2013 02:22 PM, Jiangli Zhou wrote:
>>>>> Hi,
>>>>>
>>>>> Could anyone help me review this?
>>>>>
>>>>> Thanks,
>>>>> Jiangli
>>>>>
>>>>> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review following change for JDK-8021948 
>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>>>>>
>>>>>> Both InstanceKlass::_source_file_name and 
>>>>>> InstanceKlass::_generic_signature were pointers to Symbol. They 
>>>>>> are now indexes to constant pool entries. Both fields are now u2 
>>>>>> type, and co-located with other non-pointer type fields for more 
>>>>>> efficient alignment on 64-bit machine. On 32-bit machine, the 
>>>>>> change saves 4bytes for each class.
>>>>>>
>>>>>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>>>>>> nsk.stress.testlist and nsk.jvmti.testlist.
>>>>>>
>>>>>> Thanks,
>>>>>> Jiangli
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/67cb8f3d/attachment.html 

From jiangli.zhou at oracle.com  Thu Aug 22 10:09:34 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 10:09:34 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <521635AC.6050904@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<0F3DB9FD-1630-4ECE-818C-26D2A4B3953C@oracle.com>
	<521635AC.6050904@oracle.com>
Message-ID: <521645CE.4090901@oracle.com>

Thanks, Serguei!

Jiangli

On 08/22/2013 09:00 AM, serguei.spitsyn at oracle.com wrote:
> I'm looking at it but it is time for a Town Hall meeting.
>
> Thanks,
> Serguei
>
> On 8/22/13 5:54 AM, Staffan Larsen wrote:
>> I don't claim to understand this, but if I remove the changes to 
>> jvmtiRedefineClasses.cpp in [1] the test passes. My guess is that 
>> there is no need to change the source file name cp index in 
>> scratch_class since there is no merge happening for that attribute, 
>> whatever index it has in the new class is the correct one.
>>
>> Thoughts?
>>
>> /Staffan
>>
>> [1] http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e22ee8e7ae62
>>
>>
>> On 22 aug 2013, at 13:09, Staffan Larsen <staffan.larsen at oracle.com 
>> <mailto:staffan.larsen at oracle.com>> wrote:
>>
>>> This changed caused com/sun/jdi/RedefineMulti.sh to fail. 
>>> See JDK-8023547. I'm looking at it, but if someone sees the problem, 
>>> let me know.
>>>
>>> /Staffan
>>>
>>> On 12 aug 2013, at 22:45, Jiangli Zhou <jiangli.zhou at oracle.com 
>>> <mailto:jiangli.zhou at oracle.com>> wrote:
>>>
>>>> Hi Ioi,
>>>>
>>>> Thanks for the review! I'll try those tests also.
>>>>
>>>> Thanks,
>>>> Jiangli
>>>>
>>>> On 08/12/2013 11:09 AM, Ioi Lam wrote:
>>>>> Looks good.
>>>>>
>>>>> Since you're touching the class loader code, maybe you should run 
>>>>> vm.parallel_class_loading.testlist as well.
>>>>>
>>>>> Thanks
>>>>> - Ioi
>>>>>
>>>>> On 08/09/2013 02:22 PM, Jiangli Zhou wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Could anyone help me review this?
>>>>>>
>>>>>> Thanks,
>>>>>> Jiangli
>>>>>>
>>>>>> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review following change for JDK-8021948 
>>>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>>>>>>
>>>>>>> Both InstanceKlass::_source_file_name and 
>>>>>>> InstanceKlass::_generic_signature were pointers to Symbol. They 
>>>>>>> are now indexes to constant pool entries. Both fields are now u2 
>>>>>>> type, and co-located with other non-pointer type fields for more 
>>>>>>> efficient alignment on 64-bit machine. On 32-bit machine, the 
>>>>>>> change saves 4bytes for each class.
>>>>>>>
>>>>>>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>>>>>>> nsk.stress.testlist and nsk.jvmti.testlist.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jiangli
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/52f41f66/attachment.html 

From jiangli.zhou at oracle.com  Thu Aug 22 10:27:55 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 10:27:55 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
Message-ID: <52164A1B.308@oracle.com>

Hi Staffan,

 From the log in JDK-8023547. I see the new_source_file_name_idx became 
0. We probably need to check the new index and only rewrite the source 
file name index if not 0.

-Sending cmd:  cont
--Sending cmd:  redefine shtest 
/Users/staffan/mercurial/hotspot-rt-jdk/JTwork/classes/com/sun/jdi/aa44598/vers2/shtest.class
rewrite_cp_refs scratch_class->source_file_name_index()=41
new_source_file_name_idx=0*<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<*
--Sending cmd:  stop at shtest:22

I haven't confirmed if that's the case, still trying to figure out how 
to run com/sun/jdi/RedefineMulti.sh. Do you want to give the following 
patch a try to see if it fix the problem? Also, do you have any 
instruction for how to run RedefineMulti.sh?

--- a/src/share/vm/prims/jvmtiRedefineClasses.cpp
+++ b/src/share/vm/prims/jvmtiRedefineClasses.cpp
@@ -1554,18 +1554,22 @@
      return false;
    }

-  // rewrite sourc file name index:
+  // rewrite source file name index:
    u2 source_file_name_idx = scratch_class->source_file_name_index();
    if (source_file_name_idx != 0) {
      u2 new_source_file_name_idx = find_new_index(source_file_name_idx);
- scratch_class->set_source_file_name_index(new_source_file_name_idx);
+    if (new_source_file_name_idx != 0) {
+ scratch_class->set_source_file_name_index(new_source_file_name_idx);
+    }
    }

    // rewrite class generic signature index:
    u2 generic_signature_index = scratch_class->generic_signature_index();
    if (generic_signature_index != 0) {
      u2 new_generic_signature_index = 
find_new_index(generic_signature_index);
- scratch_class->set_generic_signature_index(new_generic_signature_index);
+    if (new_generic_signature_index != 0) {
+ scratch_class->set_generic_signature_index(new_generic_signature_index);
+    }
    }


Thanks!

Jiangli

On 08/22/2013 04:09 AM, Staffan Larsen wrote:
> This changed caused com/sun/jdi/RedefineMulti.sh to fail. 
> See JDK-8023547. I'm looking at it, but if someone sees the problem, 
> let me know.
>
> /Staffan
>
> On 12 aug 2013, at 22:45, Jiangli Zhou <jiangli.zhou at oracle.com 
> <mailto:jiangli.zhou at oracle.com>> wrote:
>
>> Hi Ioi,
>>
>> Thanks for the review! I'll try those tests also.
>>
>> Thanks,
>> Jiangli
>>
>> On 08/12/2013 11:09 AM, Ioi Lam wrote:
>>> Looks good.
>>>
>>> Since you're touching the class loader code, maybe you should run 
>>> vm.parallel_class_loading.testlist as well.
>>>
>>> Thanks
>>> - Ioi
>>>
>>> On 08/09/2013 02:22 PM, Jiangli Zhou wrote:
>>>> Hi,
>>>>
>>>> Could anyone help me review this?
>>>>
>>>> Thanks,
>>>> Jiangli
>>>>
>>>> On 07/31/2013 01:51 PM, Jiangli Zhou wrote:
>>>>> Hi,
>>>>>
>>>>> Please review following change for JDK-8021948 
>>>>> <https://jbs.oracle.com/bugs/browse/JDK-8021948>:
>>>>>
>>>>> http://cr.openjdk.java.net/~jiangli/8021948/webrev.00/
>>>>>
>>>>> Both InstanceKlass::_source_file_name and 
>>>>> InstanceKlass::_generic_signature were pointers to Symbol. They 
>>>>> are now indexes to constant pool entries. Both fields are now u2 
>>>>> type, and co-located with other non-pointer type fields for more 
>>>>> efficient alignment on 64-bit machine. On 32-bit machine, the 
>>>>> change saves 4bytes for each class.
>>>>>
>>>>> Tested with JPRT, vm.quick.testlist, nsk.sajdi.testlist, 
>>>>> nsk.stress.testlist and nsk.jvmti.testlist.
>>>>>
>>>>> Thanks,
>>>>> Jiangli
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/68916c08/attachment-0001.html 

From john.coomes at oracle.com  Thu Aug 22 10:52:53 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 17:52:53 +0000
Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b104 for changeset
	42211ab0ab1c
Message-ID: <20130822175301.2633748AB6@hg.openjdk.java.net>

Changeset: 88390df7ed2c
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/88390df7ed2c

Added tag jdk8-b104 for changeset 42211ab0ab1c

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 10:52:10 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 17:52:10 +0000
Subject: hg: hsx/hotspot-emb: 5 new changesets
Message-ID: <20130822175211.2924F48AB3@hg.openjdk.java.net>

Changeset: 4fb877dfe5c4
Author:    erikj
Date:      2013-08-15 17:14 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/4fb877dfe5c4

8020411: lin32 - JDK 8 build for Linux-i586 on Oracle Linux 6.4 64-bit machines does not generate the bundles directory in the build directory
Reviewed-by: tbell

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in

Changeset: f10f673d9b17
Author:    igerasim
Date:      2013-08-16 14:43 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/f10f673d9b17

8023156: make dist-clean should remove javacservers directory
Reviewed-by: erikj

! common/makefiles/Main.gmk

Changeset: dadf49495ab4
Author:    erikj
Date:      2013-08-19 10:31 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/dadf49495ab4

8021430: 64 bit JDK build fails on windows 7 due to missing corba source files
Reviewed-by: tbell, katleman

! common/makefiles/IdlCompilation.gmk

Changeset: 96c1b9b7524b
Author:    katleman
Date:      2013-08-20 15:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/96c1b9b7524b

Merge


Changeset: c3b5197f2851
Author:    cl
Date:      2013-08-22 09:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/c3b5197f2851

Added tag jdk8-b104 for changeset 96c1b9b7524b

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 10:52:20 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 17:52:20 +0000
Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b104 for changeset
	d411c60a8c2f
Message-ID: <20130822175223.C621548AB4@hg.openjdk.java.net>

Changeset: 4e38de7c767e
Author:    cl
Date:      2013-08-22 09:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/4e38de7c767e

Added tag jdk8-b104 for changeset d411c60a8c2f

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 10:52:35 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 17:52:35 +0000
Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b104 for changeset
	a22fe9bd01e6
Message-ID: <20130822175244.CB49148AB5@hg.openjdk.java.net>

Changeset: af28b93bfb6f
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/af28b93bfb6f

Added tag jdk8-b104 for changeset a22fe9bd01e6

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 10:53:14 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 17:53:14 +0000
Subject: hg: hsx/hotspot-emb/jdk: Added tag jdk8-b104 for changeset
	f1d8d15bfcb5
Message-ID: <20130822175429.3591348AB7@hg.openjdk.java.net>

Changeset: c982f579b67e
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c982f579b67e

Added tag jdk8-b104 for changeset f1d8d15bfcb5

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 10:55:46 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 17:55:46 +0000
Subject: hg: hsx/hotspot-emb/langtools: Added tag jdk8-b104 for changeset
	dd4a00c220c6
Message-ID: <20130822175600.ABDD948AB8@hg.openjdk.java.net>

Changeset: f2ee3a4e7927
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f2ee3a4e7927

Added tag jdk8-b104 for changeset dd4a00c220c6

! .hgtags


From bill.pittore at oracle.com  Thu Aug 22 11:06:36 2013
From: bill.pittore at oracle.com (BILL PITTORE)
Date: Thu, 22 Aug 2013 14:06:36 -0400
Subject: RFR - 8023580 - Add jtreg test for 8004051 and 8005722
Message-ID: <5216532C.3080802@oracle.com>

Would like a review of the following test being added to 
hotspot/test/compiler that tests an assertion failure for both 8004051 
and 8005722.

http://cr.openjdk.java.net/~bpittore/8023580/webrev.00/

thanks,
bill



From jiangli.zhou at oracle.com  Thu Aug 22 11:09:27 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 11:09:27 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <52164A1B.308@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com>
Message-ID: <521653D7.9000404@oracle.com>


> I haven't confirmed if that's the case, still trying to figure out how 
> to run com/sun/jdi/RedefineMulti.sh. Do you want to give the following 
> patch a try to see if it fix the problem? Also, do you have any 
> instruction for how to run RedefineMulti.sh?

Running the rerun_RedefineMulti.sh, it fails with "Could not find or 
load main class shtest". It fail to run even I put the class in the 
current directory...

VM Started: No frames on the current call stack

main[1] --Sending cmd:  stop at shtest:22
Deferring breakpoint shtest:22.
It will be set after the class is loaded.
main[1] --Sending cmd:  run
 > java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b96)
Java HotSpot(TM) Server VM (build 25.0-b40-internal-debug, mixed mode)

Error: Could not find or load main class shtest
...

Thanks,
Jiangli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/bf885a55/attachment.html 

From john.coomes at oracle.com  Thu Aug 22 10:56:08 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 17:56:08 +0000
Subject: hg: hsx/hotspot-emb/nashorn: Added tag jdk8-b104 for changeset
	afc100513451
Message-ID: <20130822175613.6A17548AB9@hg.openjdk.java.net>

Changeset: 74244f43c577
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/74244f43c577

Added tag jdk8-b104 for changeset afc100513451

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 11:16:19 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 18:16:19 +0000
Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b104 for changeset
	d411c60a8c2f
Message-ID: <20130822181622.6BC2E48AC4@hg.openjdk.java.net>

Changeset: 4e38de7c767e
Author:    cl
Date:      2013-08-22 09:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/4e38de7c767e

Added tag jdk8-b104 for changeset d411c60a8c2f

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 11:16:30 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 18:16:30 +0000
Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b104 for changeset
	a22fe9bd01e6
Message-ID: <20130822181639.EF31648AC5@hg.openjdk.java.net>

Changeset: af28b93bfb6f
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/af28b93bfb6f

Added tag jdk8-b104 for changeset a22fe9bd01e6

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 11:17:30 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 18:17:30 +0000
Subject: hg: hsx/hotspot-rt/jdk: Added tag jdk8-b104 for changeset f1d8d15bfcb5
Message-ID: <20130822181835.1B09348AC8@hg.openjdk.java.net>

Changeset: c982f579b67e
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c982f579b67e

Added tag jdk8-b104 for changeset f1d8d15bfcb5

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 11:16:12 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 18:16:12 +0000
Subject: hg: hsx/hotspot-rt: 5 new changesets
Message-ID: <20130822181613.085F048AC3@hg.openjdk.java.net>

Changeset: 4fb877dfe5c4
Author:    erikj
Date:      2013-08-15 17:14 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/4fb877dfe5c4

8020411: lin32 - JDK 8 build for Linux-i586 on Oracle Linux 6.4 64-bit machines does not generate the bundles directory in the build directory
Reviewed-by: tbell

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in

Changeset: f10f673d9b17
Author:    igerasim
Date:      2013-08-16 14:43 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/f10f673d9b17

8023156: make dist-clean should remove javacservers directory
Reviewed-by: erikj

! common/makefiles/Main.gmk

Changeset: dadf49495ab4
Author:    erikj
Date:      2013-08-19 10:31 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/dadf49495ab4

8021430: 64 bit JDK build fails on windows 7 due to missing corba source files
Reviewed-by: tbell, katleman

! common/makefiles/IdlCompilation.gmk

Changeset: 96c1b9b7524b
Author:    katleman
Date:      2013-08-20 15:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/96c1b9b7524b

Merge


Changeset: c3b5197f2851
Author:    cl
Date:      2013-08-22 09:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/c3b5197f2851

Added tag jdk8-b104 for changeset 96c1b9b7524b

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 11:16:59 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 18:16:59 +0000
Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b104 for changeset
	42211ab0ab1c
Message-ID: <20130822181713.03FA048AC6@hg.openjdk.java.net>

Changeset: 88390df7ed2c
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/88390df7ed2c

Added tag jdk8-b104 for changeset 42211ab0ab1c

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 11:21:34 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 18:21:34 +0000
Subject: hg: hsx/hotspot-rt/nashorn: Added tag jdk8-b104 for changeset
	afc100513451
Message-ID: <20130822182139.EB2F348ACA@hg.openjdk.java.net>

Changeset: 74244f43c577
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/74244f43c577

Added tag jdk8-b104 for changeset afc100513451

! .hgtags


From john.coomes at oracle.com  Thu Aug 22 11:20:59 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 22 Aug 2013 18:20:59 +0000
Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b104 for changeset
	dd4a00c220c6
Message-ID: <20130822182113.6DC5548AC9@hg.openjdk.java.net>

Changeset: f2ee3a4e7927
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f2ee3a4e7927

Added tag jdk8-b104 for changeset dd4a00c220c6

! .hgtags


From harold.seigel at oracle.com  Thu Aug 22 11:52:23 2013
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Thu, 22 Aug 2013 18:52:23 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 7121403: [TESTBUG]
	runtime/7051189/Xchecksig.sh fails on 64bit solaris; ...
Message-ID: <20130822185226.D594248ACD@hg.openjdk.java.net>

Changeset: 3a57fa7a4cd0
Author:    hseigel
Date:      2013-08-22 11:52 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3a57fa7a4cd0

7121403: [TESTBUG] runtime/7051189/Xchecksig.sh fails on 64bit solaris
8023393: Need to suppress info message if -Xcheck:jni used with libjsig.dylab on Mac OSX
Summary: Rewrite 7051189 test in Java, port Linux fix for 7051189 to Mac OSX.
Reviewed-by: coleenp, dholmes, mseledtsov, ccheung

! src/os/bsd/vm/os_bsd.cpp
- test/runtime/7051189/Xchecksig.sh
+ test/runtime/XCheckJniJsig/XCheckJSig.java


From jiangli.zhou at oracle.com  Thu Aug 22 12:27:06 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 12:27:06 -0700
Subject: Request for review:8021948:Change InstanceKlass::_source_file_name
	and _generic_signature from Symbol* to constant pool index
In-Reply-To: <521653D7.9000404@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
Message-ID: <5216660A.7080801@oracle.com>

Finally I was able to reproduce the IllegalArgumentException failure 
after modifying the script. I confirmed that the proposed change fixed 
the failure. I will prepare a webrev shortly.

Thanks,
Jiangli

On 08/22/2013 11:09 AM, Jiangli Zhou wrote:
>
>> I haven't confirmed if that's the case, still trying to figure out 
>> how to run com/sun/jdi/RedefineMulti.sh. Do you want to give the 
>> following patch a try to see if it fix the problem? Also, do you have 
>> any instruction for how to run RedefineMulti.sh?
>
> Running the rerun_RedefineMulti.sh, it fails with "Could not find or 
> load main class shtest". It fail to run even I put the class in the 
> current directory...
>
> VM Started: No frames on the current call stack
>
> main[1] --Sending cmd:  stop at shtest:22
> Deferring breakpoint shtest:22.
> It will be set after the class is loaded.
> main[1] --Sending cmd:  run
> > java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b96)
> Java HotSpot(TM) Server VM (build 25.0-b40-internal-debug, mixed mode)
>
> Error: Could not find or load main class shtest
> ...
>
> Thanks,
> Jiangli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/61b569d8/attachment.html 

From jiangli.zhou at oracle.com  Thu Aug 22 12:38:54 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 12:38:54 -0700
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails with
	IllegalArgumentException after JDK-8021948
In-Reply-To: <5216660A.7080801@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com>
Message-ID: <521668CE.7010500@oracle.com>

Hi Staffan, Serguei and others,

Here is the webrev for the 8023547 fix:

   http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/

Thanks!

Jiangli

From staffan.larsen at oracle.com  Thu Aug 22 13:50:41 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Thu, 22 Aug 2013 20:50:41 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130822205047.EC64B48AD6@hg.openjdk.java.net>

Changeset: e37ab280bbce
Author:    allwin
Date:      2013-07-23 14:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e37ab280bbce

8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__"
Reviewed-by: sla, sundar, kmo
Contributed-by: yunda.mly at taobao.com

! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js

Changeset: 669d9a235486
Author:    sla
Date:      2013-08-22 14:56 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/669d9a235486

Merge



From david.r.chase at oracle.com  Thu Aug 22 14:04:22 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 22 Aug 2013 17:04:22 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <727C0BA7-6E86-4FBB-A1CB-8E7670A27214@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
	<94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
	<F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>
	<52119939.50205@oracle.com>
	<2415DA74-C2C1-4B34-8598-9A0072FA7BA9@oracle.com>
	<925B8B0B-E7A9-4934-B8F8-FAABB6492B01@oracle.com>
	<727C0BA7-6E86-4FBB-A1CB-8E7670A27214@oracle.com>
Message-ID: <E97C13DD-AC22-45B1-9CC1-1FD4A044B95C@oracle.com>

After further study, we think the different-wrong-answers are a symptom of a different bug
(to be filed) where Methodhandle processing does the wrong thing (fails to null-check or
do appropriate handshakes) when presented with empty (null) method from a virtual or
interface invocation.

So, if I may have another Reviewer (I think one more is needed for something this large)?

On 2013-08-19, at 6:46 PM, David Chase <david.r.chase at oracle.com> wrote:

> Karen Kinnear would like me to study, carefully, the wrong answer that occur in one of the default methods tests.
> Apparently this is an instance of a test where the wrong answers are still interesting -- this patch fails less, but
> in a few cases it fails differently.
> 
> David
> 
> On 2013-08-19, at 6:15 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> Looks good.  -- Chris
>> 
>> On Aug 19, 2013, at 11:13 AM, David Chase <david.r.chase at oracle.com> wrote:
>> 
>>> New version, with Christian's and John's fixes (and limited use of err_msg_res):
>>> 
>>> http://cr.openjdk.java.net/~drchase/8014013/webrev.03/
>>> 
>>> retested (jtreg) on Mac against hotspot/test/compiler, jdk/test/{jdk,java/util}
>>> 
>>> David
>>> 
>>> 
>>> On 2013-08-19, at 12:04 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>>> On 19/08/2013 8:24 AM, David Chase wrote:
>>>>> A question about err_msg_res -- should that generally be used in place of err_msg,
>>>>> or only in certain source directories, and if so, which ones?
>>>> 
>>>> I can't answer that but be aware that there is an issue with using err_msg_res as it is unclear as to whom has responsibility for ensuring there is a ResourceMark on the stack. There's an open bug on that - 8022187.
>>>> 
>>>> David
>>>> 
>>>>> On 2013-08-17, at 1:41 AM, John Rose <john.r.rose at oracle.com> wrote:
>>>>> 
>>>>>> On Aug 16, 2013, at 1:05 PM, David Chase <david.r.chase at oracle.com> wrote:
>>>>>> 
>>>>>>> How does this look?
>>>>>>> 
>>>>>>> void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
>>>>>>> if (_cp.is_null() || field_holder() != ik) {
>>>>>>> _cp = constantPoolHandle(Thread::current(), ik->constants());
>>>>>>> // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
>>>>>>> assert(field_holder() == ik, "must be already initialized to this class");
>>>>>> 
>>>>>> Good.
>>>>>> 
>>>>>> As a side note, this bit of code (and many others) assume that there is a 1-1 correspondence between constant pools and instance klasses.
>>>>>> 
>>>>>> I hope we can change this some day; the tracking bug is http://bugs.sun.com/view_bug.do?bug_id=6711913
>>>>>> 
>>>>>> ? John
>>>>> 
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130822/b69d9b51/signature.asc 

From serguei.spitsyn at oracle.com  Thu Aug 22 14:18:31 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 22 Aug 2013 14:18:31 -0700
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <521668CE.7010500@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
Message-ID: <52168027.7040903@oracle.com>

Hi Jiangli,

Thank you for the quick fix which looks fine to me.
I confirm the test is passed with it.

Staffan, thank you for the regression isolation.
I've noticed the following fragment in this file which seems has a 
similar issue:

   // We also need to rewrite the parameter name indexes, if there is
   // method parameter data present
   if(method->has_method_parameters()) {
     const int len = method->method_parameters_length();
     MethodParametersElement* elem = method->method_parameters_start();

     for (int i = 0; i < len; i++) {
       const u2 cp_index = elem[i].name_cp_index;
       elem[i].name_cp_index = find_new_index(cp_index);
     }
   }
} // end rewrite_cp_refs_in_method()

The result of the find_new_index() above is not checked for 0.

Thanks,
Serguei

On 8/22/13 12:38 PM, Jiangli Zhou wrote:
> Hi Staffan, Serguei and others,
>
> Here is the webrev for the 8023547 fix:
>
>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>
> Thanks!
>
> Jiangli


From jiangli.zhou at oracle.com  Thu Aug 22 14:24:22 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 14:24:22 -0700
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <52168027.7040903@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com>
Message-ID: <52168186.6030100@oracle.com>

Hi Serguei,

Thank you very much for the review and confirmation with the test.

Jiangli

On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
> Hi Jiangli,
>
> Thank you for the quick fix which looks fine to me.
> I confirm the test is passed with it.
>
> Staffan, thank you for the regression isolation.
> I've noticed the following fragment in this file which seems has a 
> similar issue:
>
>   // We also need to rewrite the parameter name indexes, if there is
>   // method parameter data present
>   if(method->has_method_parameters()) {
>     const int len = method->method_parameters_length();
>     MethodParametersElement* elem = method->method_parameters_start();
>
>     for (int i = 0; i < len; i++) {
>       const u2 cp_index = elem[i].name_cp_index;
>       elem[i].name_cp_index = find_new_index(cp_index);
>     }
>   }
> } // end rewrite_cp_refs_in_method()
>
> The result of the find_new_index() above is not checked for 0.
>
> Thanks,
> Serguei
>
> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>> Hi Staffan, Serguei and others,
>>
>> Here is the webrev for the 8023547 fix:
>>
>>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>
>> Thanks!
>>
>> Jiangli
>


From jiangli.zhou at oracle.com  Thu Aug 22 14:50:24 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 14:50:24 -0700
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <52168186.6030100@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
Message-ID: <521687A0.1010607@oracle.com>

Hi Serguei,

I've also made change to the case that you discovered. Please let me 
know if you think a separate bug should be filed to track it instead.

   http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/

Thanks,
Jiangli

On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
> Hi Serguei,
>
> Thank you very much for the review and confirmation with the test.
>
> Jiangli
>
> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>> Hi Jiangli,
>>
>> Thank you for the quick fix which looks fine to me.
>> I confirm the test is passed with it.
>>
>> Staffan, thank you for the regression isolation.
>> I've noticed the following fragment in this file which seems has a 
>> similar issue:
>>
>>   // We also need to rewrite the parameter name indexes, if there is
>>   // method parameter data present
>>   if(method->has_method_parameters()) {
>>     const int len = method->method_parameters_length();
>>     MethodParametersElement* elem = method->method_parameters_start();
>>
>>     for (int i = 0; i < len; i++) {
>>       const u2 cp_index = elem[i].name_cp_index;
>>       elem[i].name_cp_index = find_new_index(cp_index);
>>     }
>>   }
>> } // end rewrite_cp_refs_in_method()
>>
>> The result of the find_new_index() above is not checked for 0.
>>
>> Thanks,
>> Serguei
>>
>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>> Hi Staffan, Serguei and others,
>>>
>>> Here is the webrev for the 8023547 fix:
>>>
>>>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>
>>> Thanks!
>>>
>>> Jiangli
>>
>


From serguei.spitsyn at oracle.com  Thu Aug 22 15:10:06 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 22 Aug 2013 15:10:06 -0700
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <521687A0.1010607@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com>
Message-ID: <52168C3E.50200@oracle.com>

Hi Jiangli,

The fix is good and safe.
I'm happy you fixed another case as well!
Let's consider current bug as a clean-up issue so that we do not need to 
file a separate bug. :)

Thanks,
Serguei


On 8/22/13 2:50 PM, Jiangli Zhou wrote:
> Hi Serguei,
>
> I've also made change to the case that you discovered. Please let me 
> know if you think a separate bug should be filed to track it instead.
>
>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>
> Thanks,
> Jiangli
>
> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>> Hi Serguei,
>>
>> Thank you very much for the review and confirmation with the test.
>>
>> Jiangli
>>
>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>> Hi Jiangli,
>>>
>>> Thank you for the quick fix which looks fine to me.
>>> I confirm the test is passed with it.
>>>
>>> Staffan, thank you for the regression isolation.
>>> I've noticed the following fragment in this file which seems has a 
>>> similar issue:
>>>
>>>   // We also need to rewrite the parameter name indexes, if there is
>>>   // method parameter data present
>>>   if(method->has_method_parameters()) {
>>>     const int len = method->method_parameters_length();
>>>     MethodParametersElement* elem = method->method_parameters_start();
>>>
>>>     for (int i = 0; i < len; i++) {
>>>       const u2 cp_index = elem[i].name_cp_index;
>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>     }
>>>   }
>>> } // end rewrite_cp_refs_in_method()
>>>
>>> The result of the find_new_index() above is not checked for 0.
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>> Hi Staffan, Serguei and others,
>>>>
>>>> Here is the webrev for the 8023547 fix:
>>>>
>>>>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>
>>>> Thanks!
>>>>
>>>> Jiangli
>>>
>>
>


From jiangli.zhou at oracle.com  Thu Aug 22 15:15:58 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 15:15:58 -0700
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <52168C3E.50200@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
Message-ID: <52168D9E.8010509@oracle.com>

On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
> Hi Jiangli,
>
> The fix is good and safe.
> I'm happy you fixed another case as well!
> Let's consider current bug as a clean-up issue so that we do not need 
> to file a separate bug. :)

Ok.

Thanks,
Jiangli

>
> Thanks,
> Serguei
>
>
> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>> Hi Serguei,
>>
>> I've also made change to the case that you discovered. Please let me 
>> know if you think a separate bug should be filed to track it instead.
>>
>>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>
>> Thanks,
>> Jiangli
>>
>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>> Hi Serguei,
>>>
>>> Thank you very much for the review and confirmation with the test.
>>>
>>> Jiangli
>>>
>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Jiangli,
>>>>
>>>> Thank you for the quick fix which looks fine to me.
>>>> I confirm the test is passed with it.
>>>>
>>>> Staffan, thank you for the regression isolation.
>>>> I've noticed the following fragment in this file which seems has a 
>>>> similar issue:
>>>>
>>>>   // We also need to rewrite the parameter name indexes, if there is
>>>>   // method parameter data present
>>>>   if(method->has_method_parameters()) {
>>>>     const int len = method->method_parameters_length();
>>>>     MethodParametersElement* elem = method->method_parameters_start();
>>>>
>>>>     for (int i = 0; i < len; i++) {
>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>     }
>>>>   }
>>>> } // end rewrite_cp_refs_in_method()
>>>>
>>>> The result of the find_new_index() above is not checked for 0.
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>> Hi Staffan, Serguei and others,
>>>>>
>>>>> Here is the webrev for the 8023547 fix:
>>>>>
>>>>>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Jiangli
>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Thu Aug 22 15:34:30 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 22 Aug 2013 18:34:30 -0400
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <52168D9E.8010509@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com>
Message-ID: <521691F6.9080303@oracle.com>


Hi,
Is it the case that the old index isn't in the index map because it 
didn't change?  If so, this looks correct.
Thanks,
Coleen


On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>> Hi Jiangli,
>>
>> The fix is good and safe.
>> I'm happy you fixed another case as well!
>> Let's consider current bug as a clean-up issue so that we do not need 
>> to file a separate bug. :)
>
> Ok.
>
> Thanks,
> Jiangli
>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>> Hi Serguei,
>>>
>>> I've also made change to the case that you discovered. Please let me 
>>> know if you think a separate bug should be filed to track it instead.
>>>
>>>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>
>>> Thanks,
>>> Jiangli
>>>
>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>> Hi Serguei,
>>>>
>>>> Thank you very much for the review and confirmation with the test.
>>>>
>>>> Jiangli
>>>>
>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Hi Jiangli,
>>>>>
>>>>> Thank you for the quick fix which looks fine to me.
>>>>> I confirm the test is passed with it.
>>>>>
>>>>> Staffan, thank you for the regression isolation.
>>>>> I've noticed the following fragment in this file which seems has a 
>>>>> similar issue:
>>>>>
>>>>>   // We also need to rewrite the parameter name indexes, if there is
>>>>>   // method parameter data present
>>>>>   if(method->has_method_parameters()) {
>>>>>     const int len = method->method_parameters_length();
>>>>>     MethodParametersElement* elem = 
>>>>> method->method_parameters_start();
>>>>>
>>>>>     for (int i = 0; i < len; i++) {
>>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>>     }
>>>>>   }
>>>>> } // end rewrite_cp_refs_in_method()
>>>>>
>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>> Hi Staffan, Serguei and others,
>>>>>>
>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>
>>>>>>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Jiangli
>>>>>
>>>>
>>>
>>
>


From calvin.cheung at oracle.com  Thu Aug 22 15:55:53 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 22 Aug 2013 15:55:53 -0700
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead to
	jvm fatal error
Message-ID: <521696F9.5040403@oracle.com>

Note that the synopsis of the bug has been changed from:
"Trying to print to a pdf file with PDFill PDF&Image Writer 10.0 Build 4"

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

I've included the suggestions from Coleen and Ioi in this version of webrev:
     http://cr.openjdk.java.net/~ccheung/8020675/webrev/

Tests:
     jprt
         (in progress - only about 30 tests left on the windows 
platforms, no failure so far;
          a previous run with only Coleen's suggestions was successful)

     vm.quick.testlist on linux_x64

Please review.

thanks,
Calvin

From ioi.lam at oracle.com  Thu Aug 22 16:09:53 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 22 Aug 2013 16:09:53 -0700
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <521696F9.5040403@oracle.com>
References: <521696F9.5040403@oracle.com>
Message-ID: <52169A41.2000007@oracle.com>

Looks good to me. (Not a Reviewer).

Thanks
- Ioi

On 08/22/2013 03:55 PM, Calvin Cheung wrote:
> Note that the synopsis of the bug has been changed from:
> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0 Build 4"
>
> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>
> I've included the suggestions from Coleen and Ioi in this version of 
> webrev:
>     http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>
> Tests:
>     jprt
>         (in progress - only about 30 tests left on the windows 
> platforms, no failure so far;
>          a previous run with only Coleen's suggestions was successful)
>
>     vm.quick.testlist on linux_x64
>
> Please review.
>
> thanks,
> Calvin


From jiangli.zhou at oracle.com  Thu Aug 22 16:16:47 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 22 Aug 2013 16:16:47 -0700
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <521691F6.9080303@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
Message-ID: <52169BDF.1090800@oracle.com>

Hi Coleen,

Yes, that's the case. Thanks for the review. I'll push this to hotspot-rt.

Thanks,
Jiangli

On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>
> Hi,
> Is it the case that the old index isn't in the index map because it 
> didn't change?  If so, this looks correct.
> Thanks,
> Coleen
>
>
> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>> Hi Jiangli,
>>>
>>> The fix is good and safe.
>>> I'm happy you fixed another case as well!
>>> Let's consider current bug as a clean-up issue so that we do not 
>>> need to file a separate bug. :)
>>
>> Ok.
>>
>> Thanks,
>> Jiangli
>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>> Hi Serguei,
>>>>
>>>> I've also made change to the case that you discovered. Please let 
>>>> me know if you think a separate bug should be filed to track it 
>>>> instead.
>>>>
>>>>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>
>>>> Thanks,
>>>> Jiangli
>>>>
>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>> Hi Serguei,
>>>>>
>>>>> Thank you very much for the review and confirmation with the test.
>>>>>
>>>>> Jiangli
>>>>>
>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> Hi Jiangli,
>>>>>>
>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>> I confirm the test is passed with it.
>>>>>>
>>>>>> Staffan, thank you for the regression isolation.
>>>>>> I've noticed the following fragment in this file which seems has 
>>>>>> a similar issue:
>>>>>>
>>>>>>   // We also need to rewrite the parameter name indexes, if there is
>>>>>>   // method parameter data present
>>>>>>   if(method->has_method_parameters()) {
>>>>>>     const int len = method->method_parameters_length();
>>>>>>     MethodParametersElement* elem = 
>>>>>> method->method_parameters_start();
>>>>>>
>>>>>>     for (int i = 0; i < len; i++) {
>>>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>     }
>>>>>>   }
>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>
>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>
>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Jiangli
>>>>>>
>>>>>
>>>>
>>>
>>
>


From ioi.lam at oracle.com  Thu Aug 22 17:13:01 2013
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Fri, 23 Aug 2013 00:13:01 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130823001305.3574E48ADE@hg.openjdk.java.net>

Changeset: c062a6e1fa33
Author:    iklam
Date:      2013-08-22 10:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c062a6e1fa33

8023406: make/windows/build_vm_def.sh takes too long even when BUILD_WIN_SA != 1
Summary: Avoid dumping C++ vtable when BUILD_WIN_SA != 1
Reviewed-by: dcubed, sla, tbell

! make/windows/build_vm_def.sh
! make/windows/makefiles/debug.make
! make/windows/makefiles/fastdebug.make
! make/windows/makefiles/product.make
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/vm.make

Changeset: 811aea34d5e7
Author:    iklam
Date:      2013-08-22 13:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/811aea34d5e7

Merge



From david.holmes at oracle.com  Thu Aug 22 17:21:03 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Aug 2013 10:21:03 +1000
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <521696F9.5040403@oracle.com>
References: <521696F9.5040403@oracle.com>
Message-ID: <5216AAEF.5080101@oracle.com>

Hi Calvin,

I'm having trouble keeping track of this one ...

On 23/08/2013 8:55 AM, Calvin Cheung wrote:
> Note that the synopsis of the bug has been changed from:
> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0 Build 4"
>
> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>
> I've included the suggestions from Coleen and Ioi in this version of
> webrev:
>      http://cr.openjdk.java.net/~ccheung/8020675/webrev/

I don't understand your _has_error logic:

  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
  326   if (cpe == NULL) {
  327     _has_error = true;
  328     return NULL;

we will only hit line 327 if resolve_entry returns NULL _without_ there 
being an exception pending. How does that occur? What is different about 
the two cases regardless?

And we still have this sequence:

void ClassLoader::initialize() {
   assert(_package_hash_table == NULL, "should have been initialized by 
now.");
   EXCEPTION_MARK;
   ...
   setup_bootstrap_search_path();
     -> update_class_path_entry_list(path, false);
       ->  create_class_path_entry((char *)path, st, &new_entry, 
LazyBootClassLoader, CHECK);

So if we return after the call to create_class_path_entry with an 
exception pending we will crash when we hit the EXCEPTION_MARK. Why 
doesn't this happen?

Thanks,
David


> Tests:
>      jprt
>          (in progress - only about 30 tests left on the windows
> platforms, no failure so far;
>           a previous run with only Coleen's suggestions was successful)
>
>      vm.quick.testlist on linux_x64
>
> Please review.
>
> thanks,
> Calvin

From david.holmes at oracle.com  Thu Aug 22 19:17:45 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Aug 2013 12:17:45 +1000
Subject: RFR 8022183: GCC 4.6 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <5216277A.7090205@oracle.com>
References: <52152EE3.2040804@oracle.com> <52153ECD.9030006@oracle.com>
	<52161B70.3090907@oracle.com> <52162229.6070803@oracle.com>
	<5216277A.7090205@oracle.com>
Message-ID: <5216C649.2000208@oracle.com>

On 23/08/2013 1:00 AM, harold seigel wrote:
> Please review this updated webrev for bug 8022183:
> http://cr.openjdk.java.net/~hseigel/bug_8022183.2/
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183.2/>
>
> This change updates the comment and moves the "-fno-omit-frame-pointer"
> option to gcc.make.  This change was tested on both 32 and 64 bit Linux
> builds using NMT and GCBasher. Also, the build log was inspected to make
> sure that "-fno-omit-frame-pointer" was specified during the C++ compiles.
>
> I verified that Clang also accepts the "-fno-omit-frame-pointer" option.

Thanks for doing all that.

One minor typo in the comment: Explicity

David

> Thanks, Harold
>
>
> On 8/22/2013 10:37 AM, harold seigel wrote:
>> Yes, I'll update the comment.
>>
>> Thanks, Harold
>>
>> On 8/22/2013 10:08 AM, Coleen Phillimore wrote:
>>>
>>> Harold,
>>>
>>> Regarding the comment, isn't it not just the serviceability agent but
>>> the stack trace in hs_err and the stack walking in NMT. Isn't it
>>> generally "Stack walking in the JVM relies on frame pointer..."
>>>
>>> thanks,
>>> Coleen
>>>
>>> On 08/21/2013 06:27 PM, Daniel D. Daugherty wrote:
>>>> On 8/21/13 3:19 PM, harold seigel wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this small fix for bug 8022183.  This fix is needed
>>>>> in order to build hotspot on 32-bit Linux with newer versions of
>>>>> gcc. The fix explicitly specifies "-fno-omit-frame-pointer" in the
>>>>> makefile for 32-bit Linux.
>>>>>
>>>>> The fix was tested using NMT with -version and with GCBasher.
>>>>>
>>>>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/
>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>>>>
>>>> make/linux/makefiles/i486.make
>>>>     No comments.
>>>>
>>>> Thumbs up!
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>>>>>
>>>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>>>>>
>>>>> Thanks, Harold
>>>>
>>>
>>
>

From jiangli.zhou at oracle.com  Thu Aug 22 21:19:49 2013
From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com)
Date: Fri, 23 Aug 2013 04:19:49 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130823041955.6262D48AE3@hg.openjdk.java.net>

Changeset: ff2520b97b00
Author:    jiangli
Date:      2013-08-22 19:27 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ff2520b97b00

8023547: com/sun/jdi/RedefineMulti.sh fails with IllegalArgumentException after JDK-8021948 .
Summary: Need to check if the constant pool mapping returns 0.
Reviewed-by: coleenp, sspitsyn

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 887db75613f8
Author:    jiangli
Date:      2013-08-22 17:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/887db75613f8

Merge



From calvin.cheung at oracle.com  Thu Aug 22 23:05:29 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 22 Aug 2013 23:05:29 -0700
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <5216AAEF.5080101@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
Message-ID: <5216FBA9.50807@oracle.com>

On 8/22/2013 5:21 PM, David Holmes wrote:
> Hi Calvin,
>
> I'm having trouble keeping track of this one ...
>
> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>> Note that the synopsis of the bug has been changed from:
>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0 
>> Build 4"
>>
>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>
>> I've included the suggestions from Coleen and Ioi in this version of
>> webrev:
>>      http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>
> I don't understand your _has_error logic:
>
>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>  326   if (cpe == NULL) {
>  327     _has_error = true;
>  328     return NULL;
>
> we will only hit line 327 if resolve_entry returns NULL _without_ 
> there being an exception pending. How does that occur? What is 
> different about the two cases regardless?
The _has_error flag was suggested by Ioi and is to avoid opening the 
invalid jar file again.
The call sequence is as follows:
ClassLoader::load_classfile()
     -> LazyClassPathEntry::open_stream()
         -> LazyClassPathEntry::resolve_entry()
             -> ClassLoader::create_class_path_entry()

For second time, it'll return NULL without calling resolve_entry() again.

The LazyClassPathEntry instance is instantiated by the following calls:
ClassLoader::setup_bootstrap_search_path()
     ->ClassLoader::update_class_path_entry_list()
         ->ClassLoader::create_class_path_entry(path, &st, 
LazyBootClassLoader, CHECK)

LazyBootClassLoader is set to true by default.
>
> And we still have this sequence:
>
> void ClassLoader::initialize() {
>   assert(_package_hash_table == NULL, "should have been initialized by 
> now.");
>   EXCEPTION_MARK;
>   ...
>   setup_bootstrap_search_path();
>     -> update_class_path_entry_list(path, false);
>       ->  create_class_path_entry((char *)path, st, &new_entry, 
> LazyBootClassLoader, CHECK);
As mentioned above, this call sequence is for instantiating the 
LazyClassPathEntry instances.
>
> So if we return after the call to create_class_path_entry with an 
> exception pending we will crash when we hit the EXCEPTION_MARK. Why 
> doesn't this happen?
During vm initilization, it's ok to have exception pending. The 
destructor of ExceptionMark is as follows:
ExceptionMark::~ExceptionMark() {
   if (_thread->has_pending_exception()) {
     Handle exception(_thread, _thread->pending_exception());
     _thread->clear_pending_exception(); // Needed to avoid infinite 
recursion
     if (is_init_completed()) {
       exception->print();
       fatal("ExceptionMark destructor expects no pending exceptions");
     } else {
       vm_exit_during_initialization(exception);
     }
   }
}

So if is_init_completed() is false, it'll just print an error and exit.

thanks,
Calvin


>
> Thanks,
> David
>
>
>> Tests:
>>      jprt
>>          (in progress - only about 30 tests left on the windows
>> platforms, no failure so far;
>>           a previous run with only Coleen's suggestions was successful)
>>
>>      vm.quick.testlist on linux_x64
>>
>> Please review.
>>
>> thanks,
>> Calvin


From staffan.larsen at oracle.com  Thu Aug 22 23:23:03 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 23 Aug 2013 08:23:03 +0200
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <52169BDF.1090800@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
	<52169BDF.1090800@oracle.com>
Message-ID: <C666E31B-F502-47FA-8677-FB2733E70BFA@oracle.com>

Thanks for the quick turn-around!

/Staffan

On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:

> Hi Coleen,
> 
> Yes, that's the case. Thanks for the review. I'll push this to hotspot-rt.
> 
> Thanks,
> Jiangli
> 
> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>> 
>> Hi,
>> Is it the case that the old index isn't in the index map because it didn't change?  If so, this looks correct.
>> Thanks,
>> Coleen
>> 
>> 
>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Jiangli,
>>>> 
>>>> The fix is good and safe.
>>>> I'm happy you fixed another case as well!
>>>> Let's consider current bug as a clean-up issue so that we do not need to file a separate bug. :)
>>> 
>>> Ok.
>>> 
>>> Thanks,
>>> Jiangli
>>> 
>>>> 
>>>> Thanks,
>>>> Serguei
>>>> 
>>>> 
>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>> Hi Serguei,
>>>>> 
>>>>> I've also made change to the case that you discovered. Please let me know if you think a separate bug should be filed to track it instead.
>>>>> 
>>>>>  http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>> 
>>>>> Thanks,
>>>>> Jiangli
>>>>> 
>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>> Hi Serguei,
>>>>>> 
>>>>>> Thank you very much for the review and confirmation with the test.
>>>>>> 
>>>>>> Jiangli
>>>>>> 
>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>> Hi Jiangli,
>>>>>>> 
>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>> I confirm the test is passed with it.
>>>>>>> 
>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>> I've noticed the following fragment in this file which seems has a similar issue:
>>>>>>> 
>>>>>>>  // We also need to rewrite the parameter name indexes, if there is
>>>>>>>  // method parameter data present
>>>>>>>  if(method->has_method_parameters()) {
>>>>>>>    const int len = method->method_parameters_length();
>>>>>>>    MethodParametersElement* elem = method->method_parameters_start();
>>>>>>> 
>>>>>>>    for (int i = 0; i < len; i++) {
>>>>>>>      const u2 cp_index = elem[i].name_cp_index;
>>>>>>>      elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>    }
>>>>>>>  }
>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>> 
>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Serguei
>>>>>>> 
>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>> 
>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> 
>>>>>>>> Jiangli
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From david.holmes at oracle.com  Thu Aug 22 23:54:36 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Aug 2013 16:54:36 +1000
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <5216FBA9.50807@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
	<5216FBA9.50807@oracle.com>
Message-ID: <5217072C.5020106@oracle.com>

On 23/08/2013 4:05 PM, Calvin Cheung wrote:
> On 8/22/2013 5:21 PM, David Holmes wrote:
>> Hi Calvin,
>>
>> I'm having trouble keeping track of this one ...
>>
>> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>>> Note that the synopsis of the bug has been changed from:
>>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0
>>> Build 4"
>>>
>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>>
>>> I've included the suggestions from Coleen and Ioi in this version of
>>> webrev:
>>>      http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>
>> I don't understand your _has_error logic:
>>
>>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>  326   if (cpe == NULL) {
>>  327     _has_error = true;
>>  328     return NULL;
>>
>> we will only hit line 327 if resolve_entry returns NULL _without_
>> there being an exception pending. How does that occur? What is
>> different about the two cases regardless?
> The _has_error flag was suggested by Ioi and is to avoid opening the
> invalid jar file again.

Can't we just remove it from the classpath representation?

> The call sequence is as follows:
> ClassLoader::load_classfile()
>      -> LazyClassPathEntry::open_stream()
>          -> LazyClassPathEntry::resolve_entry()
>              -> ClassLoader::create_class_path_entry()
>
> For second time, it'll return NULL without calling resolve_entry() again.
>
> The LazyClassPathEntry instance is instantiated by the following calls:
> ClassLoader::setup_bootstrap_search_path()
>      ->ClassLoader::update_class_path_entry_list()
>          ->ClassLoader::create_class_path_entry(path, &st,
> LazyBootClassLoader, CHECK)
>
> LazyBootClassLoader is set to true by default.

Sorry but I don't see how that answers my question. Based on the below 
there isn't a second time because the first time will cause the pending 
exception which will terminate the VM. Even if we dont terminate and 
somehow call this again, we didn't set _has_error the first time anyway! ???

>>
>> And we still have this sequence:
>>
>> void ClassLoader::initialize() {
>>   assert(_package_hash_table == NULL, "should have been initialized by
>> now.");
>>   EXCEPTION_MARK;
>>   ...
>>   setup_bootstrap_search_path();
>>     -> update_class_path_entry_list(path, false);
>>       ->  create_class_path_entry((char *)path, st, &new_entry,
>> LazyBootClassLoader, CHECK);
> As mentioned above, this call sequence is for instantiating the
> LazyClassPathEntry instances.
>>
>> So if we return after the call to create_class_path_entry with an
>> exception pending we will crash when we hit the EXCEPTION_MARK. Why
>> doesn't this happen?
> During vm initilization, it's ok to have exception pending. The
> destructor of ExceptionMark is as follows:
> ExceptionMark::~ExceptionMark() {
>    if (_thread->has_pending_exception()) {
>      Handle exception(_thread, _thread->pending_exception());
>      _thread->clear_pending_exception(); // Needed to avoid infinite
> recursion
>      if (is_init_completed()) {
>        exception->print();
>        fatal("ExceptionMark destructor expects no pending exceptions");
>      } else {
>        vm_exit_during_initialization(exception);
>      }
>    }
> }
>
> So if is_init_completed() is false, it'll just print an error and exit.

So we do hit it - ok. So this yet another place where the VM should not 
abort during initialization.

Thanks,
David

> thanks,
> Calvin
>
>
>>
>> Thanks,
>> David
>>
>>
>>> Tests:
>>>      jprt
>>>          (in progress - only about 30 tests left on the windows
>>> platforms, no failure so far;
>>>           a previous run with only Coleen's suggestions was successful)
>>>
>>>      vm.quick.testlist on linux_x64
>>>
>>> Please review.
>>>
>>> thanks,
>>> Calvin
>

From poonam.bajaj at oracle.com  Thu Aug 22 23:38:37 2013
From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com)
Date: Fri, 23 Aug 2013 06:38:37 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets
Message-ID: <20130823063847.1EF2D48AE7@hg.openjdk.java.net>

Changeset: a70566600baf
Author:    poonam
Date:      2013-08-21 22:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a70566600baf

8020530: Non heap memory size calculated incorrectly
Reviewed-by: coleenp, sla
Contributed-by: vladimir.kempik at oracle.com

! src/share/vm/services/management.cpp

Changeset: 730210728146
Author:    poonam
Date:      2013-08-22 18:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/730210728146

Merge

- test/runtime/7051189/Xchecksig.sh

Changeset: 817e46dd5864
Author:    poonam
Date:      2013-08-22 21:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/817e46dd5864

Merge



From kevin.walls at oracle.com  Fri Aug 23 02:34:56 2013
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 23 Aug 2013 10:34:56 +0100
Subject: RFR 8019375: Internal symbol table size should be tunable.
Message-ID: <52172CC0.30103@oracle.com>

Hi,

I'd like to get reviews on this change to make the size of the symbol 
table tunable.  This can be a performance benefit to some apps, i.e. 
when the symbol table becomes overloaded (see PrintStringTableStatistics 
output).

This work here actually comes from Coleen.  I'm happy to take any 
further comments and update.

http://cr.openjdk.java.net/~kevinw/8019375/webrev.01/
http://bugs.sun.com/view_bug.do?bug_id=8019375

This uses SymbolTableSize as the tunable name.  (Another suggestion and 
possibile name, was PredictedMaxVMStrings to avoid talking explicity 
about the internal format.  Comments welcome!...)

Thanks
Kevin

From aleksey.shipilev at oracle.com  Fri Aug 23 04:24:04 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 23 Aug 2013 15:24:04 +0400
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
Message-ID: <52174654.8020400@oracle.com>

Hi,

The latest bug scrub identified one of the issues lacking the regression
test, where it does make sense to create one.

Background: -XX:ContendedPaddingWidth=# is range-checked on VM side to
be in [0; 8192], plus being the multiple of 8. The test checks multiple
values around the failure point.

Here's the webrev:
  http://cr.openjdk.java.net/~shade/8023638/webrev.00/

Testing:
  - this test is trivial, and excersises the common code path in VM,
hence only Linux x86_64/release was tested.

Please review!

Thanks,
-Aleksey.

From markus.gronlund at oracle.com  Fri Aug 23 05:17:12 2013
From: markus.gronlund at oracle.com (markus.gronlund at oracle.com)
Date: Fri, 23 Aug 2013 12:17:12 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8023457: Event based tracing framework
	needs a mutex for thread groups
Message-ID: <20130823121716.C49F548AFD@hg.openjdk.java.net>

Changeset: 739c309fd729
Author:    mgronlun
Date:      2013-08-23 10:36 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/739c309fd729

8023457: Event based tracing framework needs a mutex for thread groups
Reviewed-by: acorn, sla

! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp


From staffan.larsen at oracle.com  Fri Aug 23 05:27:36 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 23 Aug 2013 14:27:36 +0200
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <52169BDF.1090800@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
	<52169BDF.1090800@oracle.com>
Message-ID: <4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>

Unfortunately there are two more tests that started failing after the initial change. See: JDK-8023477.

/Staffan

On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:

> Hi Coleen,
> 
> Yes, that's the case. Thanks for the review. I'll push this to hotspot-rt.
> 
> Thanks,
> Jiangli
> 
> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>> 
>> Hi,
>> Is it the case that the old index isn't in the index map because it didn't change?  If so, this looks correct.
>> Thanks,
>> Coleen
>> 
>> 
>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Jiangli,
>>>> 
>>>> The fix is good and safe.
>>>> I'm happy you fixed another case as well!
>>>> Let's consider current bug as a clean-up issue so that we do not need to file a separate bug. :)
>>> 
>>> Ok.
>>> 
>>> Thanks,
>>> Jiangli
>>> 
>>>> 
>>>> Thanks,
>>>> Serguei
>>>> 
>>>> 
>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>> Hi Serguei,
>>>>> 
>>>>> I've also made change to the case that you discovered. Please let me know if you think a separate bug should be filed to track it instead.
>>>>> 
>>>>>  http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>> 
>>>>> Thanks,
>>>>> Jiangli
>>>>> 
>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>> Hi Serguei,
>>>>>> 
>>>>>> Thank you very much for the review and confirmation with the test.
>>>>>> 
>>>>>> Jiangli
>>>>>> 
>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>> Hi Jiangli,
>>>>>>> 
>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>> I confirm the test is passed with it.
>>>>>>> 
>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>> I've noticed the following fragment in this file which seems has a similar issue:
>>>>>>> 
>>>>>>>  // We also need to rewrite the parameter name indexes, if there is
>>>>>>>  // method parameter data present
>>>>>>>  if(method->has_method_parameters()) {
>>>>>>>    const int len = method->method_parameters_length();
>>>>>>>    MethodParametersElement* elem = method->method_parameters_start();
>>>>>>> 
>>>>>>>    for (int i = 0; i < len; i++) {
>>>>>>>      const u2 cp_index = elem[i].name_cp_index;
>>>>>>>      elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>    }
>>>>>>>  }
>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>> 
>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Serguei
>>>>>>> 
>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>> 
>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> 
>>>>>>>> Jiangli
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From yumin.qi at oracle.com  Fri Aug 23 07:53:52 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 23 Aug 2013 07:53:52 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521542A3.3020906@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
Message-ID: <52177780.3040109@oracle.com>

Could I get  a GC staff review the change? Need more reviewers to push 
this in.

Thanks
Yumin

On 8/21/2013 3:43 PM, Yumin Qi wrote:
> Hi, all
>
>   This is second version after feedback from first round.
>   The changes are:
>
>   1) file name will be based on gc log file name (-Xloggc:filename), 
> pid (process id) and time when the first rotation file created:
>        <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>   2) If rotate in same file, file name is as in 1), if rotate in 
> multiple files, .<i> will append to above file name.
>   3) every time file rotated, file name and time when file created 
> will be logged to head/tail, this is same as first version.
>   4) current file has name 
> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>        This is similar to first version.
>        By adapting such name format we will never loss logs in case 
> apps stops and restart, the log files will not be overwritten since 
> time stamp in file names.
>    5) If open file failed, turn off gc log rotation.
>         If due to some reason, file operation failed (such as 
> permission changed etc), with log file opened, logging still works, 
> but at
>         saving and renaming, the file operation will fail, this will 
> lead not all files saved.
>
> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>
>      Tested with jtreg, JPRT.
>
> Thanks
> Yumin
>
> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>> Hi,
>>
>>   Can I have your review for this small changes?
>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>
>>    This is for a enhancement to add head/tail message to the logging 
>> files to assist reading GC output.
>>    1. modified prompt message if invalid arguments used for log rotating;
>>    2. add time and file name message to log file head/tail.
>>    3. for easily identify which log file is current, use file name 
>> like <filename>.n.current, after it reaches maximum size, rename it 
>> to <filename>.n
>>         On Windows, there is no F_OK (existing test) definition, F_OK 
>> is defined as "0" and for _access of VC++, it just describes:
>>
>> modevalue
>>
>> 	
>>
>> Checks file for
>>
>> 00
>>
>> 	
>>
>> Existence only
>>
>> 02
>>
>> 	
>>
>> Write-only
>>
>> 04
>>
>> 	
>>
>> Read-only
>>
>> 06
>>
>> 	
>>
>> Read and write
>>
>>
>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>> The definition are consistent with unistd.h.
>>
>>     Test: JPRT and jtreg.
>>
>>    Thanks
>>    Yumin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130823/1a19afda/attachment.html 

From jiangli.zhou at oracle.com  Fri Aug 23 08:21:09 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 23 Aug 2013 08:21:09 -0700
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
	<52169BDF.1090800@oracle.com>
	<4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>
Message-ID: <52177DE5.9040701@oracle.com>

Hi Staffan,

Thanks for the info. Will look into that one.

Jiangli

On 08/23/2013 05:27 AM, Staffan Larsen wrote:
> Unfortunately there are two more tests that started failing after the initial change. See: JDK-8023477.
>
> /Staffan
>
> On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>
>> Hi Coleen,
>>
>> Yes, that's the case. Thanks for the review. I'll push this to hotspot-rt.
>>
>> Thanks,
>> Jiangli
>>
>> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>>> Hi,
>>> Is it the case that the old index isn't in the index map because it didn't change?  If so, this looks correct.
>>> Thanks,
>>> Coleen
>>>
>>>
>>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Hi Jiangli,
>>>>>
>>>>> The fix is good and safe.
>>>>> I'm happy you fixed another case as well!
>>>>> Let's consider current bug as a clean-up issue so that we do not need to file a separate bug. :)
>>>> Ok.
>>>>
>>>> Thanks,
>>>> Jiangli
>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>>
>>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>>> Hi Serguei,
>>>>>>
>>>>>> I've also made change to the case that you discovered. Please let me know if you think a separate bug should be filed to track it instead.
>>>>>>
>>>>>>   http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Jiangli
>>>>>>
>>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>>> Hi Serguei,
>>>>>>>
>>>>>>> Thank you very much for the review and confirmation with the test.
>>>>>>>
>>>>>>> Jiangli
>>>>>>>
>>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Hi Jiangli,
>>>>>>>>
>>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>>> I confirm the test is passed with it.
>>>>>>>>
>>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>>> I've noticed the following fragment in this file which seems has a similar issue:
>>>>>>>>
>>>>>>>>   // We also need to rewrite the parameter name indexes, if there is
>>>>>>>>   // method parameter data present
>>>>>>>>   if(method->has_method_parameters()) {
>>>>>>>>     const int len = method->method_parameters_length();
>>>>>>>>     MethodParametersElement* elem = method->method_parameters_start();
>>>>>>>>
>>>>>>>>     for (int i = 0; i < len; i++) {
>>>>>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>>     }
>>>>>>>>   }
>>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>>>
>>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>>>
>>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Jiangli


From coleen.phillimore at oracle.com  Fri Aug 23 10:50:55 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 23 Aug 2013 13:50:55 -0400
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <52174654.8020400@oracle.com>
References: <52174654.8020400@oracle.com>
Message-ID: <5217A0FF.1040406@oracle.com>


This looks good.
Thanks,
Coleen

On 8/23/2013 7:24 AM, Aleksey Shipilev wrote:
> Hi,
>
> The latest bug scrub identified one of the issues lacking the regression
> test, where it does make sense to create one.
>
> Background: -XX:ContendedPaddingWidth=# is range-checked on VM side to
> be in [0; 8192], plus being the multiple of 8. The test checks multiple
> values around the failure point.
>
> Here's the webrev:
>    http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>
> Testing:
>    - this test is trivial, and excersises the common code path in VM,
> hence only Linux x86_64/release was tested.
>
> Please review!
>
> Thanks,
> -Aleksey.


From calvin.cheung at oracle.com  Fri Aug 23 10:53:35 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 23 Aug 2013 10:53:35 -0700
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <5217072C.5020106@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
	<5216FBA9.50807@oracle.com> <5217072C.5020106@oracle.com>
Message-ID: <5217A19F.7020103@oracle.com>

On 8/22/2013 11:54 PM, David Holmes wrote:
> On 23/08/2013 4:05 PM, Calvin Cheung wrote:
>> On 8/22/2013 5:21 PM, David Holmes wrote:
>>> Hi Calvin,
>>>
>>> I'm having trouble keeping track of this one ...
>>>
>>> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>>>> Note that the synopsis of the bug has been changed from:
>>>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0
>>>> Build 4"
>>>>
>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>>>
>>>> I've included the suggestions from Coleen and Ioi in this version of
>>>> webrev:
>>>>      http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>
>>> I don't understand your _has_error logic:
>>>
>>>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>  326   if (cpe == NULL) {
>>>  327     _has_error = true;
>>>  328     return NULL;
>>>
>>> we will only hit line 327 if resolve_entry returns NULL _without_
>>> there being an exception pending. How does that occur? What is
>>> different about the two cases regardless?
>> The _has_error flag was suggested by Ioi and is to avoid opening the
>> invalid jar file again.
>
> Can't we just remove it from the classpath representation?
I think it can be done if the error happens during vm initialization.
But for this test scenario, the error happens after vm init.
Perhaps this should be addressed as a separate bug fix?
>
>> The call sequence is as follows:
>> ClassLoader::load_classfile()
>>      -> LazyClassPathEntry::open_stream()
>>          -> LazyClassPathEntry::resolve_entry()
>>              -> ClassLoader::create_class_path_entry()
>>
>> For second time, it'll return NULL without calling resolve_entry() 
>> again.
>>
>> The LazyClassPathEntry instance is instantiated by the following calls:
>> ClassLoader::setup_bootstrap_search_path()
>>      ->ClassLoader::update_class_path_entry_list()
>>          ->ClassLoader::create_class_path_entry(path, &st,
>> LazyBootClassLoader, CHECK)
>>
>> LazyBootClassLoader is set to true by default.
>
> Sorry but I don't see how that answers my question. Based on the below 
> there isn't a second time because the first time will cause the 
> pending exception which will terminate the VM. Even if we dont 
> terminate and somehow call this again, we didn't set _has_error the 
> first time anyway! ???
Let's not confused with the classes we're preloading during vm 
initialization and the applications classes after vm initialization.

Consider the following test case:
public class test3 {
     public static void main(String[] args) {
         try {
             //Class cls = Class.forName("javax.crypto.KeyGenerator");
             //System.out.println("Class = " + cls.getName());
             Class cls = Class.forName("xxx");
             System.out.println("Class = " + cls.getName());
         } catch (ClassNotFoundException cnfe) {
             cnfe.printStackTrace();
         }
         try {
             Class cls2 = Class.forName("yyy");
             System.out.println("Class = " + cls2.getName());
         } catch (ClassNotFoundException cnfe) {
             cnfe.printStackTrace();
         }
     }
}

Let's say we have a dummy.jar with 0-byte and test3.class in the same 
directory.
And command line as follows:
java -Xbootclasspath/a:dummy.jar -cp . test3

During vm init. (as in the above 
ClassLoader::setup_bootstrap_search_path() call sequence), there's no 
problem because vm doesn't need to read dummy.jar as all other preload 
classes can be found in jdk's jar files (rt.jar, jce.jar, etc.) (Note: 
this isn't the case with 7u25, we were trying to preload a non-existing 
class, please refer to my comment in the bug report.)

When vm tries to load the class for the test case (test3.class), it'll 
call into LazyClassPathEntry::open_stream(). This is the first time 
resolve_entry() returns NULL and the _has_error flag will be set to 
true. The next time vm will try to load xxx.class. Since _has_error was 
set to NULL, it will return NULL without calling resolve_entry(). Same 
story for the third time for the yyy.class.

call stack as follows:
      jvm.dll!ClassLoader::create_class_path_entry(char * path, const 
stat * st, bool lazy, Thread * __the_thread__)  Line 515    C++
      jvm.dll!LazyClassPathEntry::resolve_entry(Thread * 
__the_thread__)  Line 304 + 0x19 bytes    C++
      jvm.dll!LazyClassPathEntry::open_stream(const char * name, Thread 
* __the_thread__)  Line 325 + 0xc bytes    C++
      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
__the_thread__)  Line 909 + 0x1b bytes    C++
      jvm.dll!SystemDictionary::load_instance_class(Symbol * class_name, 
Handle class_loader, Thread * __the_thread__)  Line 1301 + 0x14 bytes    C++
      jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
name, Handle class_loader, Handle protection_domain, Thread * 
__the_thread__)  Line 779 + 0x18 bytes    C++
      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
Handle class_loader, Handle protection_domain, Thread * __the_thread__)  
Line 232 + 0x15 bytes    C++
      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
Thread * __the_thread__)  Line 237 + 0x23 bytes    C++
 >    jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
name)  Line 770 + 0x12 bytes    C++
      java.dll!70671e8c()

I've just noticed that there's a slight error in my change in line #325 
of classLoader.cpp:

ClassPathEntry* cpe = resolve_entry(CHECK_NULL);

should be

ClassPathEntry* cpe = resolve_entry(THREAD);

Otherwise, it'll skip the rest of the statements.
I'll update webrev shortly.

>
>>>
>>> And we still have this sequence:
>>>
>>> void ClassLoader::initialize() {
>>>   assert(_package_hash_table == NULL, "should have been initialized by
>>> now.");
>>>   EXCEPTION_MARK;
>>>   ...
>>>   setup_bootstrap_search_path();
>>>     -> update_class_path_entry_list(path, false);
>>>       ->  create_class_path_entry((char *)path, st, &new_entry,
>>> LazyBootClassLoader, CHECK);
>> As mentioned above, this call sequence is for instantiating the
>> LazyClassPathEntry instances.
>>>
>>> So if we return after the call to create_class_path_entry with an
>>> exception pending we will crash when we hit the EXCEPTION_MARK. Why
>>> doesn't this happen?
>> During vm initilization, it's ok to have exception pending. The
>> destructor of ExceptionMark is as follows:
>> ExceptionMark::~ExceptionMark() {
>>    if (_thread->has_pending_exception()) {
>>      Handle exception(_thread, _thread->pending_exception());
>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>> recursion
>>      if (is_init_completed()) {
>>        exception->print();
>>        fatal("ExceptionMark destructor expects no pending exceptions");
>>      } else {
>>        vm_exit_during_initialization(exception);
>>      }
>>    }
>> }
>>
>> So if is_init_completed() is false, it'll just print an error and exit.
>
> So we do hit it - ok. So this yet another place where the VM should 
> not abort during initialization.
Yes and this is for preloading class scenario during vm init.
IMHO, I don't think we should change the behavior now.

thanks,
Calvin
>
> Thanks,
> David
>
>> thanks,
>> Calvin
>>
>>
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>> Tests:
>>>>      jprt
>>>>          (in progress - only about 30 tests left on the windows
>>>> platforms, no failure so far;
>>>>           a previous run with only Coleen's suggestions was 
>>>> successful)
>>>>
>>>>      vm.quick.testlist on linux_x64
>>>>
>>>> Please review.
>>>>
>>>> thanks,
>>>> Calvin
>>


From jiangli.zhou at oracle.com  Fri Aug 23 11:00:07 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 23 Aug 2013 11:00:07 -0700
Subject: Request for review:8023547:com/sun/jdi/RedefineMulti.sh fails
	with IllegalArgumentException after JDK-8021948
In-Reply-To: <52177DE5.9040701@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
	<52169BDF.1090800@oracle.com>
	<4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>
	<52177DE5.9040701@oracle.com>
Message-ID: <5217A327.2080506@oracle.com>

I found the issue in the SA code. For class without generic signature, 
the InstanceKlass::_generic_signature_index is 0. Need to check for this 
case in the SA code. I'm working on the fix and doing testing.

Thanks,
Jiangli

On 08/23/2013 08:21 AM, Jiangli Zhou wrote:
> Hi Staffan,
>
> Thanks for the info. Will look into that one.
>
> Jiangli
>
> On 08/23/2013 05:27 AM, Staffan Larsen wrote:
>> Unfortunately there are two more tests that started failing after the 
>> initial change. See: JDK-8023477.
>>
>> /Staffan
>>
>> On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>>
>>> Hi Coleen,
>>>
>>> Yes, that's the case. Thanks for the review. I'll push this to 
>>> hotspot-rt.
>>>
>>> Thanks,
>>> Jiangli
>>>
>>> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>>>> Hi,
>>>> Is it the case that the old index isn't in the index map because it 
>>>> didn't change?  If so, this looks correct.
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
>>>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> Hi Jiangli,
>>>>>>
>>>>>> The fix is good and safe.
>>>>>> I'm happy you fixed another case as well!
>>>>>> Let's consider current bug as a clean-up issue so that we do not 
>>>>>> need to file a separate bug. :)
>>>>> Ok.
>>>>>
>>>>> Thanks,
>>>>> Jiangli
>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>>
>>>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>>>> Hi Serguei,
>>>>>>>
>>>>>>> I've also made change to the case that you discovered. Please 
>>>>>>> let me know if you think a separate bug should be filed to track 
>>>>>>> it instead.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jiangli
>>>>>>>
>>>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>>>> Hi Serguei,
>>>>>>>>
>>>>>>>> Thank you very much for the review and confirmation with the test.
>>>>>>>>
>>>>>>>> Jiangli
>>>>>>>>
>>>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>> Hi Jiangli,
>>>>>>>>>
>>>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>>>> I confirm the test is passed with it.
>>>>>>>>>
>>>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>>>> I've noticed the following fragment in this file which seems 
>>>>>>>>> has a similar issue:
>>>>>>>>>
>>>>>>>>>   // We also need to rewrite the parameter name indexes, if 
>>>>>>>>> there is
>>>>>>>>>   // method parameter data present
>>>>>>>>>   if(method->has_method_parameters()) {
>>>>>>>>>     const int len = method->method_parameters_length();
>>>>>>>>>     MethodParametersElement* elem = 
>>>>>>>>> method->method_parameters_start();
>>>>>>>>>
>>>>>>>>>     for (int i = 0; i < len; i++) {
>>>>>>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>>>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>>>     }
>>>>>>>>>   }
>>>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>>>>
>>>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Serguei
>>>>>>>>>
>>>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>>>>
>>>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> Jiangli
>


From mikhailo.seledtsov at oracle.com  Fri Aug 23 11:06:02 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Fri, 23 Aug 2013 14:06:02 -0400
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <5217A0FF.1040406@oracle.com>
References: <52174654.8020400@oracle.com> <5217A0FF.1040406@oracle.com>
Message-ID: <5217A48A.3020000@oracle.com>

Hi Aleksey,

  Test looks good.

Misha

On 8/23/2013 1:50 PM, Coleen Phillimore wrote:
>
> This looks good.
> Thanks,
> Coleen
>
> On 8/23/2013 7:24 AM, Aleksey Shipilev wrote:
>> Hi,
>>
>> The latest bug scrub identified one of the issues lacking the regression
>> test, where it does make sense to create one.
>>
>> Background: -XX:ContendedPaddingWidth=# is range-checked on VM side to
>> be in [0; 8192], plus being the multiple of 8. The test checks multiple
>> values around the failure point.
>>
>> Here's the webrev:
>>    http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>>
>> Testing:
>>    - this test is trivial, and excersises the common code path in VM,
>> hence only Linux x86_64/release was tested.
>>
>> Please review!
>>
>> Thanks,
>> -Aleksey.
>


From coleen.phillimore at oracle.com  Fri Aug 23 11:26:48 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 23 Aug 2013 14:26:48 -0400
Subject: RFR (S): 8022683 : JNI GetStringUTFChars should return NULL on
	allocation failure not abort the VM
In-Reply-To: <521496C5.6020805@oracle.com>
References: <520E3B16.2040100@oracle.com> <52119635.1050908@oracle.com>
	<521496C5.6020805@oracle.com>
Message-ID: <5217A968.4070702@oracle.com>


DavidS,

I think this change looks good.  Going from a vm_exit_out_of_memory() in 
JVM to dtrace (sdt probes on some linuxes) not providing information, 
which it couldn't before with a crash, is still an improvement.

Coleen

On 8/21/2013 6:30 AM, David Simms wrote:
>
> Been a little side-track, reply inline...
>
> On 19/08/13 05:51, David Holmes wrote:
>> Hi David,
>>
>> On 17/08/2013 12:45 AM, David Simms wrote:
>>> Hello all,
>>>
>>> Need reviewers on a JDK8 fix for:
>>> http://bugs.sun.com/view_bug.do?bug_id=8022683
>>>
>>> Found the following functions need to return NULL as suggested by the
>>> JNI spec
>>> (http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html): 
>>>
>>>
>>>   * GetStringChars()
>>>   * GetStringUTFChars()
>>>   * Get<PrimitiveType>ArrayElements() family of array getters (same
>>>     generating macro).
>>>
>>> Although the specification suggests OOME may be thrown by certain
>>> functions, the documentation on the aforementioned functions does not
>>> suggest "throws". So they return NULL now without aborting the JVM as
>>> before.
>>
>> There is always come contention with the JNI spec as to whether the 
>> intent is as defined by the original JNI spec book, or whether it is 
>> reflected in what is considered the "official spec". :)
>>
> Agreed, but let's just take the documentation developers have to go on.
>>> It was assumed the meaning of "isCopy" is undefined given a NULL 
>>> result,
>>> in keeping with the rest of jni.cpp.
>>
>> Even so I think it preferable to not set it unless the operation 
>> succeeds.
>>
> Done
>>> Also discovered allocation.hpp macros missing proper argument 
>>> bracketing
>>> (e.g. size passed in NEW_C_HEAP_ARRAY_RETURN_NULL()), fixed them up
>>> since I was there (and they caused trouble).
>>
>> I can only see size causing a problem because it is used in an 
>> expression. The rest seems somewhat overkill.
>>
> Fine, no need to get too happy, also done.
>
>     Been used to as a matter of practice bracketing anything involving
>     possible expression/calculation, i.e. pointer math.
>
> Updated webrev:
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~dsimms/8022683/
>>> <http://cr.openjdk.java.net/%7Edsimms/8022683/>
>>
>> One concern I have is in how the dtrace probes will handle things if 
>> buf/result is NULL?
> Previous behavior was to exit the vm with OOM error (i.e.: 
> vm_exit_out_of_memory()), which dtrace doesn't handle (so we are good).
>
> Begs the question, how many applications will now simply crash within 
> their native code, and does this change reduce the amount of 
> diagnostics information. Whilst I prefer to stick the API 
> documentation, wondering if this will be practical...  Okay tested 
> with -Xcheck:jni which catches the problem (so we are good).
>
>>
>> Thanks,
>> David
>>
>>> Testing:
>>>
>>> Attached "unit test" to bug, naive test program to trigger OOM. It is
>>> not suitable for automated testing. Ideally require hooks into the JVM
>>> to simulate OOM during JNI calls.
>>>
>>> Cheers
>>> /David Simms
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130823/d3c8fe37/attachment-0001.html 

From alejandro.murillo at oracle.com  Fri Aug 23 11:37:27 2013
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 23 Aug 2013 18:37:27 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 36 new changesets
Message-ID: <20130823183858.8524F48B15@hg.openjdk.java.net>

Changeset: c93e0a210e1b
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c93e0a210e1b

Added tag jdk8-b104 for changeset 104743074675

! .hgtags

Changeset: d96f52012aaa
Author:    rdurbin
Date:      2013-08-14 15:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d96f52012aaa

8005073: [TESTBUG] remove crufty '_g' support from HS tests
Summary: remove crufty '_g' support from HS tests
Reviewed-by: dcubed, sla

! test/Makefile

Changeset: 740e263c80c6
Author:    hseigel
Date:      2013-08-15 20:04 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/740e263c80c6

8003424: Enable Class Data Sharing for CompressedOops
8016729: ObjectAlignmentInBytes=16 now forces the use of heap based compressed oops
8005933: The -Xshare:auto option is ignored for -server
Summary: Move klass metaspace above the heap and support CDS with compressed klass ptrs.
Reviewed-by: coleenp, kvn, mgerdin, tschatzl, stefank

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/relocInfo_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klass.inline.hpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/utilities/globalDefinitions.hpp
+ test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java
+ test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java
+ test/runtime/CDSCompressedKPtrs/XShareAuto.java
! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java

Changeset: e5003079dfa5
Author:    dcubed
Date:      2013-08-16 10:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e5003079dfa5

Merge

! src/share/vm/utilities/globalDefinitions.hpp

Changeset: b1fd869e7df0
Author:    minqi
Date:      2013-08-19 09:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b1fd869e7df0

8023188: Unsafe volatile double store on bsd is broken
Reviewed-by: dcubed, dholmes
Contributed-by: yumin.qi at oracle.com

! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp

Changeset: 1a8fb39bdbc4
Author:    ehelin
Date:      2013-08-07 16:47 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1a8fb39bdbc4

8014659: NPG: performance counters for compressed klass space
Reviewed-by: mgerdin, coleenp, hseigel, jmasa, ctornqvi

! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp
! src/share/vm/memory/metaspaceCounters.hpp
! src/share/vm/memory/universe.cpp
+ test/gc/metaspace/TestMetaspacePerfCounters.java
+ test/testlibrary/AssertsTest.java
+ test/testlibrary/com/oracle/java/testlibrary/Asserts.java
+ test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java
+ test/testlibrary/com/oracle/java/testlibrary/InMemoryJavaCompiler.java
+ test/testlibrary/com/oracle/java/testlibrary/InputArguments.java
+ test/testlibrary/com/oracle/java/testlibrary/PerfCounter.java
+ test/testlibrary/com/oracle/java/testlibrary/PerfCounters.java

Changeset: 878bb0b7e799
Author:    ehelin
Date:      2013-08-19 17:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/878bb0b7e799

Merge


Changeset: 10c59b8021ec
Author:    kevinw
Date:      2013-08-19 14:28 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/10c59b8021ec

8022655: ClassDump ignored jarStream setting
Reviewed-by: minqi, sla

! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
! test/compiler/ciReplay/common.sh

Changeset: 9011aa6843ce
Author:    kevinw
Date:      2013-08-19 22:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9011aa6843ce

Merge


Changeset: e22ee8e7ae62
Author:    jiangli
Date:      2013-08-19 14:59 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e22ee8e7ae62

8021948: Change InstanceKlass::_source_file_name and _generic_signature from Symbol* to constant pool indexes.
Summary: Change InstanceKlass::_source_file_name and _generic_signature to u2 fields.
Reviewed-by: coleenp, iklam

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: aeebffb56606
Author:    jiangli
Date:      2013-08-20 00:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/aeebffb56606

Merge


Changeset: 9d6c9b0a8f15
Author:    dcubed
Date:      2013-08-20 13:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9d6c9b0a8f15

8023287: HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3"
Summary: Recognize 0x5120 as "Sun Studio 12u3".
Reviewed-by: dholmes, coleenp

! src/share/vm/runtime/vm_version.cpp

Changeset: afbe18ae0905
Author:    bharadwaj
Date:      2013-08-15 11:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/afbe18ae0905

8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases
Summary: Corrected details
Reviewed-by: kvn, twisti, rbackman
Contributed-by: david.r.chase at oracle.com

! src/cpu/x86/vm/templateInterpreter_x86_64.cpp

Changeset: adb9a7d94cb5
Author:    adlertz
Date:      2013-08-16 10:23 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/adb9a7d94cb5

8023003: Cleanup the public interface to PhaseCFG
Summary: public methods that don't need to be public should be private.
Reviewed-by: kvn, twisti

! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 6c72125a2f40
Author:    iignatyev
Date:      2013-08-16 17:34 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6c72125a2f40

8016456: ciReplay test assumes TIERED compilation is available
Reviewed-by: vlivanov, kvn, dholmes

! test/compiler/ciReplay/common.sh

Changeset: f99558245e5c
Author:    iignatyev
Date:      2013-08-14 23:50 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f99558245e5c

8022832: Add WB APIs for OSR compilation
Reviewed-by: kvn

! src/share/vm/oops/method.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/compiler/whitebox/SetForceInlineMethodTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: d18b10b1fd09
Author:    iignatyev
Date:      2013-08-16 13:39 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d18b10b1fd09

Merge


Changeset: 4b2838704fd5
Author:    kvn
Date:      2013-08-16 14:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4b2838704fd5

8021898: Broken JIT compiler optimization for loop unswitching
Summary: fix method clone_projs() to clone all related MachProj nodes.
Reviewed-by: roland, adlertz

! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 6725044c5725
Author:    rbackman
Date:      2013-08-19 09:33 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6725044c5725

Merge

! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/oops/method.cpp

Changeset: e16282db4946
Author:    twisti
Date:      2013-08-20 10:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e16282db4946

8022956: Clang: enable return type warnings on BSD
Reviewed-by: coleenp, sla

! make/bsd/makefiles/gcc.make
! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/frame_zero.cpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/icBuffer_zero.cpp
! src/cpu/zero/vm/interp_masm_zero.hpp
! src/cpu/zero/vm/interpreter_zero.cpp
! src/cpu/zero/vm/nativeInst_zero.hpp
! src/cpu/zero/vm/register_zero.cpp
! src/cpu/zero/vm/relocInfo_zero.cpp
! src/cpu/zero/vm/sharedRuntime_zero.cpp
! src/cpu/zero/vm/vtableStubs_zero.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp

Changeset: acedd49a1bce
Author:    rbackman
Date:      2013-08-08 03:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/acedd49a1bce

8022675: Redundant class init check
Reviewed-by: kvn, twisti

! src/share/vm/opto/library_call.cpp

Changeset: 4dece0730c50
Author:    rbackman
Date:      2013-08-22 18:37 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4dece0730c50

Merge

! src/share/vm/runtime/vmStructs.cpp
! test/compiler/ciReplay/common.sh

Changeset: 5888334c9c24
Author:    johnc
Date:      2013-08-15 10:52 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5888334c9c24

7145569: G1: optimize nmethods scanning
Summary: Add a list of nmethods to the RSet for a region that contain references into the region. Skip scanning the code cache during root scanning and scan the nmethod lists during RSet scanning instead.
Reviewed-by: tschatzl, brutisso, mgerdin, twisti, kvn

! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/iterator.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/utilities/growableArray.hpp

Changeset: 8088d93a63e6
Author:    brutisso
Date:      2013-08-15 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8088d93a63e6

Merge


Changeset: 9720d338b1d5
Author:    brutisso
Date:      2013-08-16 11:26 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9720d338b1d5

8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0
Reviewed-by: stefank, mgerdin

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: d0afbee540e0
Author:    stefank
Date:      2013-08-19 13:44 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d0afbee540e0

8023227: Enhance layout_helper_log2_element_size assert
Reviewed-by: mgerdin, jmasa

! src/share/vm/oops/klass.hpp

Changeset: 422920730903
Author:    ehelin
Date:      2013-08-19 18:17 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/422920730903

8023219: NPG: MetaspaceMemoryPool should report statistics for all of metaspace
Reviewed-by: stefank, sjohanss

! src/share/vm/services/memoryPool.cpp

Changeset: 57600c4aeabe
Author:    jmasa
Date:      2013-08-19 08:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/57600c4aeabe

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 31f220c1f789
Author:    jmasa
Date:      2013-08-20 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/31f220c1f789

Merge


Changeset: 61521bd65100
Author:    tschatzl
Date:      2013-08-21 10:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/61521bd65100

8022784: TaskQueue misses minimal documentation and references for analysis
Summary: Add appropriate documentation and references to publication to allow easier analysis of the TaskQueue implementation.
Reviewed-by: dholmes, ehelin

! src/share/vm/utilities/taskqueue.hpp

Changeset: cb9da55b1990
Author:    jmasa
Date:      2013-08-14 19:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cb9da55b1990

8021809: Partitioning based on eden sampling during allocation not reset correctly
Reviewed-by: ysr, hiroshi

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: b51aee2dd8bb
Author:    jmasa
Date:      2013-08-22 11:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b51aee2dd8bb

Merge

! src/share/vm/oops/klass.hpp

Changeset: 8009adb44523
Author:    jmasa
Date:      2013-08-22 14:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8009adb44523

Merge


Changeset: c1604d5885a6
Author:    amurillo
Date:      2013-08-23 03:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c1604d5885a6

Merge


Changeset: acac3bde66b2
Author:    amurillo
Date:      2013-08-23 03:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/acac3bde66b2

Added tag hs25-b47 for changeset c1604d5885a6

! .hgtags

Changeset: 73921c720b94
Author:    amurillo
Date:      2013-08-23 03:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/73921c720b94

8023635: new hotspot build - hs25-b48
Reviewed-by: jcoomes

! make/hotspot_version


From mikhailo.seledtsov at oracle.com  Fri Aug 23 11:45:49 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Fri, 23 Aug 2013 14:45:49 -0400
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <5217A19F.7020103@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
	<5216FBA9.50807@oracle.com> <5217072C.5020106@oracle.com>
	<5217A19F.7020103@oracle.com>
Message-ID: <5217ADDD.9090604@oracle.com>

Hi Calvin,

  I only reviewed the test portion. It looks good to me.

Misha

On 8/23/2013 1:53 PM, Calvin Cheung wrote:
> On 8/22/2013 11:54 PM, David Holmes wrote:
>> On 23/08/2013 4:05 PM, Calvin Cheung wrote:
>>> On 8/22/2013 5:21 PM, David Holmes wrote:
>>>> Hi Calvin,
>>>>
>>>> I'm having trouble keeping track of this one ...
>>>>
>>>> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>>>>> Note that the synopsis of the bug has been changed from:
>>>>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0
>>>>> Build 4"
>>>>>
>>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>>>>
>>>>> I've included the suggestions from Coleen and Ioi in this version of
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>
>>>> I don't understand your _has_error logic:
>>>>
>>>>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>>  326   if (cpe == NULL) {
>>>>  327     _has_error = true;
>>>>  328     return NULL;
>>>>
>>>> we will only hit line 327 if resolve_entry returns NULL _without_
>>>> there being an exception pending. How does that occur? What is
>>>> different about the two cases regardless?
>>> The _has_error flag was suggested by Ioi and is to avoid opening the
>>> invalid jar file again.
>>
>> Can't we just remove it from the classpath representation?
> I think it can be done if the error happens during vm initialization.
> But for this test scenario, the error happens after vm init.
> Perhaps this should be addressed as a separate bug fix?
>>
>>> The call sequence is as follows:
>>> ClassLoader::load_classfile()
>>>      -> LazyClassPathEntry::open_stream()
>>>          -> LazyClassPathEntry::resolve_entry()
>>>              -> ClassLoader::create_class_path_entry()
>>>
>>> For second time, it'll return NULL without calling resolve_entry() 
>>> again.
>>>
>>> The LazyClassPathEntry instance is instantiated by the following calls:
>>> ClassLoader::setup_bootstrap_search_path()
>>>      ->ClassLoader::update_class_path_entry_list()
>>>          ->ClassLoader::create_class_path_entry(path, &st,
>>> LazyBootClassLoader, CHECK)
>>>
>>> LazyBootClassLoader is set to true by default.
>>
>> Sorry but I don't see how that answers my question. Based on the 
>> below there isn't a second time because the first time will cause the 
>> pending exception which will terminate the VM. Even if we dont 
>> terminate and somehow call this again, we didn't set _has_error the 
>> first time anyway! ???
> Let's not confused with the classes we're preloading during vm 
> initialization and the applications classes after vm initialization.
>
> Consider the following test case:
> public class test3 {
>     public static void main(String[] args) {
>         try {
>             //Class cls = Class.forName("javax.crypto.KeyGenerator");
>             //System.out.println("Class = " + cls.getName());
>             Class cls = Class.forName("xxx");
>             System.out.println("Class = " + cls.getName());
>         } catch (ClassNotFoundException cnfe) {
>             cnfe.printStackTrace();
>         }
>         try {
>             Class cls2 = Class.forName("yyy");
>             System.out.println("Class = " + cls2.getName());
>         } catch (ClassNotFoundException cnfe) {
>             cnfe.printStackTrace();
>         }
>     }
> }
>
> Let's say we have a dummy.jar with 0-byte and test3.class in the same 
> directory.
> And command line as follows:
> java -Xbootclasspath/a:dummy.jar -cp . test3
>
> During vm init. (as in the above 
> ClassLoader::setup_bootstrap_search_path() call sequence), there's no 
> problem because vm doesn't need to read dummy.jar as all other preload 
> classes can be found in jdk's jar files (rt.jar, jce.jar, etc.) (Note: 
> this isn't the case with 7u25, we were trying to preload a 
> non-existing class, please refer to my comment in the bug report.)
>
> When vm tries to load the class for the test case (test3.class), it'll 
> call into LazyClassPathEntry::open_stream(). This is the first time 
> resolve_entry() returns NULL and the _has_error flag will be set to 
> true. The next time vm will try to load xxx.class. Since _has_error 
> was set to NULL, it will return NULL without calling resolve_entry(). 
> Same story for the third time for the yyy.class.
>
> call stack as follows:
>      jvm.dll!ClassLoader::create_class_path_entry(char * path, const 
> stat * st, bool lazy, Thread * __the_thread__)  Line 515    C++
>      jvm.dll!LazyClassPathEntry::resolve_entry(Thread * 
> __the_thread__)  Line 304 + 0x19 bytes    C++
>      jvm.dll!LazyClassPathEntry::open_stream(const char * name, Thread 
> * __the_thread__)  Line 325 + 0xc bytes    C++
>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
> __the_thread__)  Line 909 + 0x1b bytes    C++
>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
> class_name, Handle class_loader, Thread * __the_thread__)  Line 1301 + 
> 0x14 bytes    C++
> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
> name, Handle class_loader, Handle protection_domain, Thread * 
> __the_thread__)  Line 779 + 0x18 bytes    C++
>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
> Handle class_loader, Handle protection_domain, Thread * 
> __the_thread__)  Line 232 + 0x15 bytes    C++
>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
> >    jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
> name)  Line 770 + 0x12 bytes    C++
>      java.dll!70671e8c()
>
> I've just noticed that there's a slight error in my change in line 
> #325 of classLoader.cpp:
>
> ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>
> should be
>
> ClassPathEntry* cpe = resolve_entry(THREAD);
>
> Otherwise, it'll skip the rest of the statements.
> I'll update webrev shortly.
>
>>
>>>>
>>>> And we still have this sequence:
>>>>
>>>> void ClassLoader::initialize() {
>>>>   assert(_package_hash_table == NULL, "should have been initialized by
>>>> now.");
>>>>   EXCEPTION_MARK;
>>>>   ...
>>>>   setup_bootstrap_search_path();
>>>>     -> update_class_path_entry_list(path, false);
>>>>       ->  create_class_path_entry((char *)path, st, &new_entry,
>>>> LazyBootClassLoader, CHECK);
>>> As mentioned above, this call sequence is for instantiating the
>>> LazyClassPathEntry instances.
>>>>
>>>> So if we return after the call to create_class_path_entry with an
>>>> exception pending we will crash when we hit the EXCEPTION_MARK. Why
>>>> doesn't this happen?
>>> During vm initilization, it's ok to have exception pending. The
>>> destructor of ExceptionMark is as follows:
>>> ExceptionMark::~ExceptionMark() {
>>>    if (_thread->has_pending_exception()) {
>>>      Handle exception(_thread, _thread->pending_exception());
>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>> recursion
>>>      if (is_init_completed()) {
>>>        exception->print();
>>>        fatal("ExceptionMark destructor expects no pending exceptions");
>>>      } else {
>>>        vm_exit_during_initialization(exception);
>>>      }
>>>    }
>>> }
>>>
>>> So if is_init_completed() is false, it'll just print an error and exit.
>>
>> So we do hit it - ok. So this yet another place where the VM should 
>> not abort during initialization.
> Yes and this is for preloading class scenario during vm init.
> IMHO, I don't think we should change the behavior now.
>
> thanks,
> Calvin
>>
>> Thanks,
>> David
>>
>>> thanks,
>>> Calvin
>>>
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>> Tests:
>>>>>      jprt
>>>>>          (in progress - only about 30 tests left on the windows
>>>>> platforms, no failure so far;
>>>>>           a previous run with only Coleen's suggestions was 
>>>>> successful)
>>>>>
>>>>>      vm.quick.testlist on linux_x64
>>>>>
>>>>> Please review.
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130823/d33aa125/attachment-0001.html 

From coleen.phillimore at oracle.com  Fri Aug 23 11:54:07 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 23 Aug 2013 14:54:07 -0400
Subject: RFR 8019375: Internal symbol table size should be tunable.
In-Reply-To: <52172CC0.30103@oracle.com>
References: <52172CC0.30103@oracle.com>
Message-ID: <5217AFCF.1040200@oracle.com>


Hi Kevin,

I'm sorry I didn't warn you but I think there are serviceability agent 
changes with this change.   For some reason, I think the SA duplicates 
code in the JVM for the symbol table.

You might get away with only changing this line in 
agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java

     symbolTableSize = 
db.lookupIntConstant("SymbolTable::symbol_table_size").intValue(); to 
use SymbolTableSize.

Then run the nsk.sajdi.testlist tests.

Thanks,
Coleen

On 8/23/2013 5:34 AM, Kevin Walls wrote:
> Hi,
>
> I'd like to get reviews on this change to make the size of the symbol 
> table tunable.  This can be a performance benefit to some apps, i.e. 
> when the symbol table becomes overloaded (see 
> PrintStringTableStatistics output).
>
> This work here actually comes from Coleen.  I'm happy to take any 
> further comments and update.
>
> http://cr.openjdk.java.net/~kevinw/8019375/webrev.01/
> http://bugs.sun.com/view_bug.do?bug_id=8019375
>
> This uses SymbolTableSize as the tunable name.  (Another suggestion 
> and possibile name, was PredictedMaxVMStrings to avoid talking 
> explicity about the internal format.  Comments welcome!...)
>
> Thanks
> Kevin


From daniel.daugherty at oracle.com  Fri Aug 23 13:14:14 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 23 Aug 2013 13:14:14 -0700 (PDT)
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <52174654.8020400@oracle.com>
References: <52174654.8020400@oracle.com>
Message-ID: <5217C296.7070807@oracle.com>

On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
> Hi,
>
> The latest bug scrub identified one of the issues lacking the regression
> test, where it does make sense to create one.
>
> Background: -XX:ContendedPaddingWidth=# is range-checked on VM side to
> be in [0; 8192], plus being the multiple of 8. The test checks multiple
> values around the failure point.
>
> Here's the webrev:
>    http://cr.openjdk.java.net/~shade/8023638/webrev.00/

hotspot/test/runtime/contended/Options.java
     I count 11 Java process invocations. Will the default timeout
     of 120 seconds be enough for a fastdebug '-server -Xcomp'
     run on something like Solaris SPARC.

     The fragments:

         "must be the between"
         "must be the multiple of 8"

     probably match the real error messages, but those messages
     aren't quite proper English. I expected:

         "must be in between"
         "must be a multiple of 8"


Dan


>
> Testing:
>    - this test is trivial, and excersises the common code path in VM,
> hence only Linux x86_64/release was tested.
>
> Please review!
>
> Thanks,
> -Aleksey.


From calvin.cheung at oracle.com  Fri Aug 23 13:23:04 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 23 Aug 2013 13:23:04 -0700
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <5217ADDD.9090604@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
	<5216FBA9.50807@oracle.com> <5217072C.5020106@oracle.com>
	<5217A19F.7020103@oracle.com> <5217ADDD.9090604@oracle.com>
Message-ID: <5217C4A8.8000000@oracle.com>

Hi Misha,

Thanks for reviewing the test case.

All,

I've updated the webrev with the one-line change in classLoader.cpp.
http://cr.openjdk.java.net/~ccheung/8020675/webrev/

thanks,
Calvin

On 8/23/2013 11:45 AM, Mikhailo Seledtsov wrote:
> Hi Calvin,
>
>  I only reviewed the test portion. It looks good to me.
>
> Misha
>
> On 8/23/2013 1:53 PM, Calvin Cheung wrote:
>> On 8/22/2013 11:54 PM, David Holmes wrote:
>>> On 23/08/2013 4:05 PM, Calvin Cheung wrote:
>>>> On 8/22/2013 5:21 PM, David Holmes wrote:
>>>>> Hi Calvin,
>>>>>
>>>>> I'm having trouble keeping track of this one ...
>>>>>
>>>>> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>>>>>> Note that the synopsis of the bug has been changed from:
>>>>>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0
>>>>>> Build 4"
>>>>>>
>>>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>>>>>
>>>>>> I've included the suggestions from Coleen and Ioi in this version of
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>
>>>>> I don't understand your _has_error logic:
>>>>>
>>>>>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>>>  326   if (cpe == NULL) {
>>>>>  327     _has_error = true;
>>>>>  328     return NULL;
>>>>>
>>>>> we will only hit line 327 if resolve_entry returns NULL _without_
>>>>> there being an exception pending. How does that occur? What is
>>>>> different about the two cases regardless?
>>>> The _has_error flag was suggested by Ioi and is to avoid opening the
>>>> invalid jar file again.
>>>
>>> Can't we just remove it from the classpath representation?
>> I think it can be done if the error happens during vm initialization.
>> But for this test scenario, the error happens after vm init.
>> Perhaps this should be addressed as a separate bug fix?
>>>
>>>> The call sequence is as follows:
>>>> ClassLoader::load_classfile()
>>>>      -> LazyClassPathEntry::open_stream()
>>>>          -> LazyClassPathEntry::resolve_entry()
>>>>              -> ClassLoader::create_class_path_entry()
>>>>
>>>> For second time, it'll return NULL without calling resolve_entry() 
>>>> again.
>>>>
>>>> The LazyClassPathEntry instance is instantiated by the following 
>>>> calls:
>>>> ClassLoader::setup_bootstrap_search_path()
>>>>      ->ClassLoader::update_class_path_entry_list()
>>>>          ->ClassLoader::create_class_path_entry(path, &st,
>>>> LazyBootClassLoader, CHECK)
>>>>
>>>> LazyBootClassLoader is set to true by default.
>>>
>>> Sorry but I don't see how that answers my question. Based on the 
>>> below there isn't a second time because the first time will cause 
>>> the pending exception which will terminate the VM. Even if we dont 
>>> terminate and somehow call this again, we didn't set _has_error the 
>>> first time anyway! ???
>> Let's not confused with the classes we're preloading during vm 
>> initialization and the applications classes after vm initialization.
>>
>> Consider the following test case:
>> public class test3 {
>>     public static void main(String[] args) {
>>         try {
>>             //Class cls = Class.forName("javax.crypto.KeyGenerator");
>>             //System.out.println("Class = " + cls.getName());
>>             Class cls = Class.forName("xxx");
>>             System.out.println("Class = " + cls.getName());
>>         } catch (ClassNotFoundException cnfe) {
>>             cnfe.printStackTrace();
>>         }
>>         try {
>>             Class cls2 = Class.forName("yyy");
>>             System.out.println("Class = " + cls2.getName());
>>         } catch (ClassNotFoundException cnfe) {
>>             cnfe.printStackTrace();
>>         }
>>     }
>> }
>>
>> Let's say we have a dummy.jar with 0-byte and test3.class in the same 
>> directory.
>> And command line as follows:
>> java -Xbootclasspath/a:dummy.jar -cp . test3
>>
>> During vm init. (as in the above 
>> ClassLoader::setup_bootstrap_search_path() call sequence), there's no 
>> problem because vm doesn't need to read dummy.jar as all other 
>> preload classes can be found in jdk's jar files (rt.jar, jce.jar, 
>> etc.) (Note: this isn't the case with 7u25, we were trying to preload 
>> a non-existing class, please refer to my comment in the bug report.)
>>
>> When vm tries to load the class for the test case (test3.class), 
>> it'll call into LazyClassPathEntry::open_stream(). This is the first 
>> time resolve_entry() returns NULL and the _has_error flag will be set 
>> to true. The next time vm will try to load xxx.class. Since 
>> _has_error was set to NULL, it will return NULL without calling 
>> resolve_entry(). Same story for the third time for the yyy.class.
>>
>> call stack as follows:
>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, const 
>> stat * st, bool lazy, Thread * __the_thread__)  Line 515    C++
>>      jvm.dll!LazyClassPathEntry::resolve_entry(Thread * 
>> __the_thread__)  Line 304 + 0x19 bytes    C++
>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name, 
>> Thread * __the_thread__)  Line 325 + 0xc bytes    C++
>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>> __the_thread__)  Line 909 + 0x1b bytes    C++
>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>> class_name, Handle class_loader, Thread * __the_thread__) Line 1301 + 
>> 0x14 bytes    C++
>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>> name, Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Handle class_loader, Handle protection_domain, Thread * 
>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>> >    jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>> name)  Line 770 + 0x12 bytes    C++
>>      java.dll!70671e8c()
>>
>> I've just noticed that there's a slight error in my change in line 
>> #325 of classLoader.cpp:
>>
>> ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>
>> should be
>>
>> ClassPathEntry* cpe = resolve_entry(THREAD);
>>
>> Otherwise, it'll skip the rest of the statements.
>> I'll update webrev shortly.
>>
>>>
>>>>>
>>>>> And we still have this sequence:
>>>>>
>>>>> void ClassLoader::initialize() {
>>>>>   assert(_package_hash_table == NULL, "should have been 
>>>>> initialized by
>>>>> now.");
>>>>>   EXCEPTION_MARK;
>>>>>   ...
>>>>>   setup_bootstrap_search_path();
>>>>>     -> update_class_path_entry_list(path, false);
>>>>>       ->  create_class_path_entry((char *)path, st, &new_entry,
>>>>> LazyBootClassLoader, CHECK);
>>>> As mentioned above, this call sequence is for instantiating the
>>>> LazyClassPathEntry instances.
>>>>>
>>>>> So if we return after the call to create_class_path_entry with an
>>>>> exception pending we will crash when we hit the EXCEPTION_MARK. Why
>>>>> doesn't this happen?
>>>> During vm initilization, it's ok to have exception pending. The
>>>> destructor of ExceptionMark is as follows:
>>>> ExceptionMark::~ExceptionMark() {
>>>>    if (_thread->has_pending_exception()) {
>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>> recursion
>>>>      if (is_init_completed()) {
>>>>        exception->print();
>>>>        fatal("ExceptionMark destructor expects no pending 
>>>> exceptions");
>>>>      } else {
>>>>        vm_exit_during_initialization(exception);
>>>>      }
>>>>    }
>>>> }
>>>>
>>>> So if is_init_completed() is false, it'll just print an error and 
>>>> exit.
>>>
>>> So we do hit it - ok. So this yet another place where the VM should 
>>> not abort during initialization.
>> Yes and this is for preloading class scenario during vm init.
>> IMHO, I don't think we should change the behavior now.
>>
>> thanks,
>> Calvin
>>>
>>> Thanks,
>>> David
>>>
>>>> thanks,
>>>> Calvin
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> Tests:
>>>>>>      jprt
>>>>>>          (in progress - only about 30 tests left on the windows
>>>>>> platforms, no failure so far;
>>>>>>           a previous run with only Coleen's suggestions was 
>>>>>> successful)
>>>>>>
>>>>>>      vm.quick.testlist on linux_x64
>>>>>>
>>>>>> Please review.
>>>>>>
>>>>>> thanks,
>>>>>> Calvin
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130823/a2692cbf/attachment-0001.html 

From jiangli.zhou at oracle.com  Fri Aug 23 14:49:50 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 23 Aug 2013 14:49:50 -0700
Subject: Request for review:8023477: Invalid CP index when reading ConstantPool
In-Reply-To: <5217A327.2080506@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
	<52169BDF.1090800@oracle.com>
	<4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>
	<52177DE5.9040701@oracle.com> <5217A327.2080506@oracle.com>
Message-ID: <5217D8FE.9090507@oracle.com>

Hi,

Please review the fix for 8023477:

   http://cr.openjdk.java.net/~jiangli/8023477/webrev.00/

Both tests reported by the bug failed due to the same problem. They both 
are passing now.

The original memory reduction change for 8021948 turned out to be a 
little trickier than I expected.

Thanks,
Jiangli


On 08/23/2013 11:00 AM, Jiangli Zhou wrote:
> I found the issue in the SA code. For class without generic signature, 
> the InstanceKlass::_generic_signature_index is 0. Need to check for 
> this case in the SA code. I'm working on the fix and doing testing.
>
> Thanks,
> Jiangli
>
> On 08/23/2013 08:21 AM, Jiangli Zhou wrote:
>> Hi Staffan,
>>
>> Thanks for the info. Will look into that one.
>>
>> Jiangli
>>
>> On 08/23/2013 05:27 AM, Staffan Larsen wrote:
>>> Unfortunately there are two more tests that started failing after 
>>> the initial change. See: JDK-8023477.
>>>
>>> /Staffan
>>>
>>> On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>>>
>>>> Hi Coleen,
>>>>
>>>> Yes, that's the case. Thanks for the review. I'll push this to 
>>>> hotspot-rt.
>>>>
>>>> Thanks,
>>>> Jiangli
>>>>
>>>> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>>>>> Hi,
>>>>> Is it the case that the old index isn't in the index map because 
>>>>> it didn't change?  If so, this looks correct.
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>>
>>>>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>>>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>> Hi Jiangli,
>>>>>>>
>>>>>>> The fix is good and safe.
>>>>>>> I'm happy you fixed another case as well!
>>>>>>> Let's consider current bug as a clean-up issue so that we do not 
>>>>>>> need to file a separate bug. :)
>>>>>> Ok.
>>>>>>
>>>>>> Thanks,
>>>>>> Jiangli
>>>>>>
>>>>>>> Thanks,
>>>>>>> Serguei
>>>>>>>
>>>>>>>
>>>>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>>>>> Hi Serguei,
>>>>>>>>
>>>>>>>> I've also made change to the case that you discovered. Please 
>>>>>>>> let me know if you think a separate bug should be filed to 
>>>>>>>> track it instead.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jiangli
>>>>>>>>
>>>>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>>>>> Hi Serguei,
>>>>>>>>>
>>>>>>>>> Thank you very much for the review and confirmation with the 
>>>>>>>>> test.
>>>>>>>>>
>>>>>>>>> Jiangli
>>>>>>>>>
>>>>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>> Hi Jiangli,
>>>>>>>>>>
>>>>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>>>>> I confirm the test is passed with it.
>>>>>>>>>>
>>>>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>>>>> I've noticed the following fragment in this file which seems 
>>>>>>>>>> has a similar issue:
>>>>>>>>>>
>>>>>>>>>>   // We also need to rewrite the parameter name indexes, if 
>>>>>>>>>> there is
>>>>>>>>>>   // method parameter data present
>>>>>>>>>>   if(method->has_method_parameters()) {
>>>>>>>>>>     const int len = method->method_parameters_length();
>>>>>>>>>>     MethodParametersElement* elem = 
>>>>>>>>>> method->method_parameters_start();
>>>>>>>>>>
>>>>>>>>>>     for (int i = 0; i < len; i++) {
>>>>>>>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>>>>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>>>>     }
>>>>>>>>>>   }
>>>>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>>>>>
>>>>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Serguei
>>>>>>>>>>
>>>>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>>>>>
>>>>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Jiangli
>>
>


From mikhailo.seledtsov at oracle.com  Fri Aug 23 15:06:08 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Fri, 23 Aug 2013 18:06:08 -0400
Subject: RFR - 8023580 - Add jtreg test for 8004051 and 8005722
In-Reply-To: <5216532C.3080802@oracle.com>
References: <5216532C.3080802@oracle.com>
Message-ID: <5217DCD0.1050005@oracle.com>

Hi Bill,

  The test looks good to me, though I am not an official Reviewer.
One style comment: in Java tests, unlike the C/C++ code, the style 
guideline is to use 4 spaces for tabulation/indentation.

Misha

On 8/22/2013 2:06 PM, BILL PITTORE wrote:
> Would like a review of the following test being added to 
> hotspot/test/compiler that tests an assertion failure for both 8004051 
> and 8005722.
>
> http://cr.openjdk.java.net/~bpittore/8023580/webrev.00/
>
> thanks,
> bill
>
>


From serguei.spitsyn at oracle.com  Fri Aug 23 15:27:05 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 23 Aug 2013 15:27:05 -0700 (PDT)
Subject: Request for review:8023477: Invalid CP index when reading
	ConstantPool
In-Reply-To: <5217D8FE.9090507@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com>
	<521653D7.9000404@oracle.com> <5216660A.7080801@oracle.com>
	<521668CE.7010500@oracle.com> <52168027.7040903@oracle.com>
	<52168186.6030100@oracle.com> <521687A0.1010607@oracle.com>
	<52168C3E.50200@oracle.com> <52168D9E.8010509@oracle.com>
	<521691F6.9080303@oracle.com> <52169BDF.1090800@oracle.com>
	<4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>
	<52177DE5.9040701@oracle.com> <5217A327.2080506@oracle.com>
	<5217D8FE.9090507@oracle.com>
Message-ID: <5217E1B9.4010203@oracle.com>

Hi Jiangli,

The fix looks good and safe.

Thanks,
Serguei

On 8/23/13 2:49 PM, Jiangli Zhou wrote:
> Hi,
>
> Please review the fix for 8023477:
>
>   http://cr.openjdk.java.net/~jiangli/8023477/webrev.00/
>
> Both tests reported by the bug failed due to the same problem. They 
> both are passing now.
>
> The original memory reduction change for 8021948 turned out to be a 
> little trickier than I expected.
>
> Thanks,
> Jiangli
>
>
> On 08/23/2013 11:00 AM, Jiangli Zhou wrote:
>> I found the issue in the SA code. For class without generic 
>> signature, the InstanceKlass::_generic_signature_index is 0. Need to 
>> check for this case in the SA code. I'm working on the fix and doing 
>> testing.
>>
>> Thanks,
>> Jiangli
>>
>> On 08/23/2013 08:21 AM, Jiangli Zhou wrote:
>>> Hi Staffan,
>>>
>>> Thanks for the info. Will look into that one.
>>>
>>> Jiangli
>>>
>>> On 08/23/2013 05:27 AM, Staffan Larsen wrote:
>>>> Unfortunately there are two more tests that started failing after 
>>>> the initial change. See: JDK-8023477.
>>>>
>>>> /Staffan
>>>>
>>>> On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> 
>>>> wrote:
>>>>
>>>>> Hi Coleen,
>>>>>
>>>>> Yes, that's the case. Thanks for the review. I'll push this to 
>>>>> hotspot-rt.
>>>>>
>>>>> Thanks,
>>>>> Jiangli
>>>>>
>>>>> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>>>>>> Hi,
>>>>>> Is it the case that the old index isn't in the index map because 
>>>>>> it didn't change?  If so, this looks correct.
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>>
>>>>>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>>>>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Hi Jiangli,
>>>>>>>>
>>>>>>>> The fix is good and safe.
>>>>>>>> I'm happy you fixed another case as well!
>>>>>>>> Let's consider current bug as a clean-up issue so that we do 
>>>>>>>> not need to file a separate bug. :)
>>>>>>> Ok.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jiangli
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>>>>>> Hi Serguei,
>>>>>>>>>
>>>>>>>>> I've also made change to the case that you discovered. Please 
>>>>>>>>> let me know if you think a separate bug should be filed to 
>>>>>>>>> track it instead.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jiangli
>>>>>>>>>
>>>>>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>>>>>> Hi Serguei,
>>>>>>>>>>
>>>>>>>>>> Thank you very much for the review and confirmation with the 
>>>>>>>>>> test.
>>>>>>>>>>
>>>>>>>>>> Jiangli
>>>>>>>>>>
>>>>>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>> Hi Jiangli,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>>>>>> I confirm the test is passed with it.
>>>>>>>>>>>
>>>>>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>>>>>> I've noticed the following fragment in this file which seems 
>>>>>>>>>>> has a similar issue:
>>>>>>>>>>>
>>>>>>>>>>>   // We also need to rewrite the parameter name indexes, if 
>>>>>>>>>>> there is
>>>>>>>>>>>   // method parameter data present
>>>>>>>>>>>   if(method->has_method_parameters()) {
>>>>>>>>>>>     const int len = method->method_parameters_length();
>>>>>>>>>>>     MethodParametersElement* elem = 
>>>>>>>>>>> method->method_parameters_start();
>>>>>>>>>>>
>>>>>>>>>>>     for (int i = 0; i < len; i++) {
>>>>>>>>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>>>>>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>>>>>     }
>>>>>>>>>>>   }
>>>>>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>>>>>>
>>>>>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Serguei
>>>>>>>>>>>
>>>>>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> Jiangli
>>>
>>
>


From jiangli.zhou at oracle.com  Fri Aug 23 15:29:57 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 23 Aug 2013 15:29:57 -0700
Subject: Request for review:8023477: Invalid CP index when reading
	ConstantPool
In-Reply-To: <5217E1B9.4010203@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
	<52169BDF.1090800@oracle.com>
	<4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>
	<52177DE5.9040701@oracle.com> <5217A327.2080506@oracle.com>
	<5217D8FE.9090507@oracle.com> <5217E1B9.4010203@oracle.com>
Message-ID: <5217E265.7060005@oracle.com>

Thanks again, Serguei!

Jiangli

On 08/23/2013 03:27 PM, serguei.spitsyn at oracle.com wrote:
> Hi Jiangli,
>
> The fix looks good and safe.
>
> Thanks,
> Serguei
>
> On 8/23/13 2:49 PM, Jiangli Zhou wrote:
>> Hi,
>>
>> Please review the fix for 8023477:
>>
>>   http://cr.openjdk.java.net/~jiangli/8023477/webrev.00/
>>
>> Both tests reported by the bug failed due to the same problem. They 
>> both are passing now.
>>
>> The original memory reduction change for 8021948 turned out to be a 
>> little trickier than I expected.
>>
>> Thanks,
>> Jiangli
>>
>>
>> On 08/23/2013 11:00 AM, Jiangli Zhou wrote:
>>> I found the issue in the SA code. For class without generic 
>>> signature, the InstanceKlass::_generic_signature_index is 0. Need to 
>>> check for this case in the SA code. I'm working on the fix and doing 
>>> testing.
>>>
>>> Thanks,
>>> Jiangli
>>>
>>> On 08/23/2013 08:21 AM, Jiangli Zhou wrote:
>>>> Hi Staffan,
>>>>
>>>> Thanks for the info. Will look into that one.
>>>>
>>>> Jiangli
>>>>
>>>> On 08/23/2013 05:27 AM, Staffan Larsen wrote:
>>>>> Unfortunately there are two more tests that started failing after 
>>>>> the initial change. See: JDK-8023477.
>>>>>
>>>>> /Staffan
>>>>>
>>>>> On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> 
>>>>> wrote:
>>>>>
>>>>>> Hi Coleen,
>>>>>>
>>>>>> Yes, that's the case. Thanks for the review. I'll push this to 
>>>>>> hotspot-rt.
>>>>>>
>>>>>> Thanks,
>>>>>> Jiangli
>>>>>>
>>>>>> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>>>>>>> Hi,
>>>>>>> Is it the case that the old index isn't in the index map because 
>>>>>>> it didn't change?  If so, this looks correct.
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>>
>>>>>>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>>>>>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>> Hi Jiangli,
>>>>>>>>>
>>>>>>>>> The fix is good and safe.
>>>>>>>>> I'm happy you fixed another case as well!
>>>>>>>>> Let's consider current bug as a clean-up issue so that we do 
>>>>>>>>> not need to file a separate bug. :)
>>>>>>>> Ok.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jiangli
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Serguei
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>>>>>>> Hi Serguei,
>>>>>>>>>>
>>>>>>>>>> I've also made change to the case that you discovered. Please 
>>>>>>>>>> let me know if you think a separate bug should be filed to 
>>>>>>>>>> track it instead.
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Jiangli
>>>>>>>>>>
>>>>>>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>>>>>>> Hi Serguei,
>>>>>>>>>>>
>>>>>>>>>>> Thank you very much for the review and confirmation with the 
>>>>>>>>>>> test.
>>>>>>>>>>>
>>>>>>>>>>> Jiangli
>>>>>>>>>>>
>>>>>>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>>> Hi Jiangli,
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>>>>>>> I confirm the test is passed with it.
>>>>>>>>>>>>
>>>>>>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>>>>>>> I've noticed the following fragment in this file which 
>>>>>>>>>>>> seems has a similar issue:
>>>>>>>>>>>>
>>>>>>>>>>>>   // We also need to rewrite the parameter name indexes, if 
>>>>>>>>>>>> there is
>>>>>>>>>>>>   // method parameter data present
>>>>>>>>>>>>   if(method->has_method_parameters()) {
>>>>>>>>>>>>     const int len = method->method_parameters_length();
>>>>>>>>>>>>     MethodParametersElement* elem = 
>>>>>>>>>>>> method->method_parameters_start();
>>>>>>>>>>>>
>>>>>>>>>>>>     for (int i = 0; i < len; i++) {
>>>>>>>>>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>>>>>>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>>>>>>     }
>>>>>>>>>>>>   }
>>>>>>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>>>>>>>
>>>>>>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Serguei
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jiangli
>>>>
>>>
>>
>


From tao.mao at oracle.com  Fri Aug 23 15:33:23 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Fri, 23 Aug 2013 15:33:23 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <52177780.3040109@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com>
Message-ID: <5217E333.9020802@oracle.com>

Hi,

I reviewed most of the code and test-ran a build from it. It's a very 
cool and important improvement.

Thank you for putting together these on our wishlist for long.

Below are some comments.

1. src/share/vm/runtime/arguments.cpp

- 1853 "To enable GC log rotation, use -Xloggc:<filename> 
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
-XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
+ 1853 "To enable GC log rotation, use -Xloggc:<filename> 
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
-XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"

Please consider adding [g|G] to GCLogFileSize suggestion.

I worked on a problem of enabling gc log limit over 2G (JDK-7122222). So 
it seems that customers sometimes want gc logs to be very large.

2. src/share/vm/runtime/arguments.hpp

(1) with the current changeset, we only append date&time to file_name w/ 
+UseGCLogFileRotation; if not, we won't have date&time info.

I think it would be useful to let both cases (w/ and w/o 
UseGCLogFileRotation) have date&time in order to solve the overwritten 
problem (e.g. JDK-8020667). In fact, having that, we actually solve 
JDK-8020667.

If you want to have that, basically you need to work on the FileStream 
constructor methods fileStream().

(2) Would it be better to rename method name reformat_filename() to 
extend_filename()?

(3) Typos and suggestion
537 // rotate file in names filename.0, filename.1, ..., 
filename.<NumberOfGCLogFiles - 1>
*=> extended_filename.0*

538 // filename contains pid and time when the fist file created. The 
current filename is
*=> *the*first *file created.

539 // gc_log_file_name + pid<pid> + YYYY-MM-DD_HH-MM-SS.<i>.current, 
where i is current
540 // rotation file number. After it reaches max file size, the file 
will be saved and
541 // renamed with .current removed from its tail.

3. For your point 5), I don't quite get it. In my test-run, I tried to 
change file permission to unreadable and unwritable, but VM would later 
change the permission back anyway.

So could you bring up some use cases of that functionality to give more 
details?

4. Will you write jtreg tests for this functionality? It looks possible 
to write some tests, at least checking the format of log names.

Thanks.
Tao

On 8/23/13 7:53 AM, Yumin Qi wrote:
> Could I get  a GC staff review the change? Need more reviewers to push 
> this in.
>
> Thanks
> Yumin
>
> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   This is second version after feedback from first round.
>>   The changes are:
>>
>>   1) file name will be based on gc log file name (-Xloggc:filename), 
>> pid (process id) and time when the first rotation file created:
>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>   2) If rotate in same file, file name is as in 1), if rotate in 
>> multiple files, .<i> will append to above file name.
>>   3) every time file rotated, file name and time when file created 
>> will be logged to head/tail, this is same as first version.
>>   4) current file has name 
>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>        This is similar to first version.
>>        By adapting such name format we will never loss logs in case 
>> apps stops and restart, the log files will not be overwritten since 
>> time stamp in file names.
>>    5) If open file failed, turn off gc log rotation.
>>         If due to some reason, file operation failed (such as 
>> permission changed etc), with log file opened, logging still works, 
>> but at
>>         saving and renaming, the file operation will fail, this will 
>> lead not all files saved.
>>
>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>
>>      Tested with jtreg, JPRT.
>>
>> Thanks
>> Yumin
>>
>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>> Hi,
>>>
>>>   Can I have your review for this small changes?
>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>
>>>    This is for a enhancement to add head/tail message to the logging 
>>> files to assist reading GC output.
>>>    1. modified prompt message if invalid arguments used for log 
>>> rotating;
>>>    2. add time and file name message to log file head/tail.
>>>    3. for easily identify which log file is current, use file name 
>>> like <filename>.n.current, after it reaches maximum size, rename it 
>>> to <filename>.n
>>>         On Windows, there is no F_OK (existing test) definition, 
>>> F_OK is defined as "0" and for _access of VC++, it just describes:
>>>
>>> modevalue
>>>
>>> 	
>>>
>>> Checks file for
>>>
>>> 00
>>>
>>> 	
>>>
>>> Existence only
>>>
>>> 02
>>>
>>> 	
>>>
>>> Write-only
>>>
>>> 04
>>>
>>> 	
>>>
>>> Read-only
>>>
>>> 06
>>>
>>> 	
>>>
>>> Read and write
>>>
>>>
>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>> The definition are consistent with unistd.h.
>>>
>>>     Test: JPRT and jtreg.
>>>
>>>    Thanks
>>>    Yumin
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130823/6d7bbca8/attachment-0001.html 

From yumin.qi at oracle.com  Fri Aug 23 16:05:40 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 23 Aug 2013 16:05:40 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <5217E333.9020802@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
Message-ID: <5217EAC4.9090001@oracle.com>

Tao,

   Thanks for your review.

On 8/23/2013 3:33 PM, Tao Mao wrote:
> Hi,
>
> I reviewed most of the code and test-ran a build from it. It's a very 
> cool and important improvement.
>
> Thank you for putting together these on our wishlist for long.
>
> Below are some comments.
>
> 1. src/share/vm/runtime/arguments.cpp
>
> - 1853 "To enable GC log rotation, use -Xloggc:<filename> 
> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
> + 1853 "To enable GC log rotation, use -Xloggc:<filename> 
> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>
> Please consider adding [g|G] to GCLogFileSize suggestion.
>
> I worked on a problem of enabling gc log limit over 2G (JDK-7122222). 
> So it seems that customers sometimes want gc logs to be very large.
>
Sure, will add.
> 2. src/share/vm/runtime/arguments.hpp
>
> (1) with the current changeset, we only append date&time to file_name 
> w/ +UseGCLogFileRotation; if not, we won't have date&time info.
>
> I think it would be useful to let both cases (w/ and w/o 
> UseGCLogFileRotation) have date&time in order to solve the overwritten 
> problem (e.g. JDK-8020667). In fact, having that, we actually solve 
> JDK-8020667.
>
> If you want to have that, basically you need to work on the FileStream 
> constructor methods fileStream().
>
I can change that, if no objection from others. This also will simplify 
the setting of file name here.

> (2) Would it be better to rename method name reformat_filename() to 
> extend_filename()?
>
> (3) Typos and suggestion
> 537 // rotate file in names filename.0, filename.1, ..., 
> filename.<NumberOfGCLogFiles - 1>
> *=> extended_filename.0*
>
> 538 // filename contains pid and time when the fist file created. The 
> current filename is
> *=> *the*first *file created.
>
> 539 // gc_log_file_name + pid<pid> + YYYY-MM-DD_HH-MM-SS.<i>.current, 
> where i is current
> 540 // rotation file number. After it reaches max file size, the file 
> will be saved and
> 541 // renamed with .current removed from its tail.
>
Will change that.
> 3. For your point 5), I don't quite get it. In my test-run, I tried to 
> change file permission to unreadable and unwritable, but VM would 
> later change the permission back anyway.
>
> So could you bring up some use cases of that functionality to give 
> more details?
>
Changing file permission will not stop the file create, in this 
rotation, the file opened/saved/removed/renamed -> then repeat. What I 
have done is change the while directory to read only, then the create 
failed so rotation stopped.

> 4. Will you write jtreg tests for this functionality? It looks 
> possible to write some tests, at least checking the format of log names.
>
Good suggestion, I will add one.

> Thanks.
> Tao
>
> On 8/23/13 7:53 AM, Yumin Qi wrote:
>> Could I get  a GC staff review the change? Need more reviewers to 
>> push this in.
>>
>> Thanks
>> Yumin
>>
>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   This is second version after feedback from first round.
>>>   The changes are:
>>>
>>>   1) file name will be based on gc log file name (-Xloggc:filename), 
>>> pid (process id) and time when the first rotation file created:
>>>        <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>   2) If rotate in same file, file name is as in 1), if rotate in 
>>> multiple files, .<i> will append to above file name.
>>>   3) every time file rotated, file name and time when file created 
>>> will be logged to head/tail, this is same as first version.
>>>   4) current file has name 
>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>        This is similar to first version.
>>>        By adapting such name format we will never loss logs in case 
>>> apps stops and restart, the log files will not be overwritten since 
>>> time stamp in file names.
>>>    5) If open file failed, turn off gc log rotation.
>>>         If due to some reason, file operation failed (such as 
>>> permission changed etc), with log file opened, logging still works, 
>>> but at
>>>         saving and renaming, the file operation will fail, this will 
>>> lead not all files saved.
>>>
>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>
>>>      Tested with jtreg, JPRT.
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>> Hi,
>>>>
>>>>   Can I have your review for this small changes?
>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>
>>>>    This is for a enhancement to add head/tail message to the 
>>>> logging files to assist reading GC output.
>>>>    1. modified prompt message if invalid arguments used for log 
>>>> rotating;
>>>>    2. add time and file name message to log file head/tail.
>>>>    3. for easily identify which log file is current, use file name 
>>>> like <filename>.n.current, after it reaches maximum size, rename it 
>>>> to <filename>.n
>>>>         On Windows, there is no F_OK (existing test) definition, 
>>>> F_OK is defined as "0" and for _access of VC++, it just describes:
>>>>
>>>> modevalue
>>>>
>>>> 	
>>>>
>>>> Checks file for
>>>>
>>>> 00
>>>>
>>>> 	
>>>>
>>>> Existence only
>>>>
>>>> 02
>>>>
>>>> 	
>>>>
>>>> Write-only
>>>>
>>>> 04
>>>>
>>>> 	
>>>>
>>>> Read-only
>>>>
>>>> 06
>>>>
>>>> 	
>>>>
>>>> Read and write
>>>>
>>>>
>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>> The definition are consistent with unistd.h.
>>>>
>>>>     Test: JPRT and jtreg.
>>>>
>>>>    Thanks
>>>>    Yumin
>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130823/d736c396/attachment.html 

From bill.pittore at oracle.com  Fri Aug 23 16:34:31 2013
From: bill.pittore at oracle.com (BILL PITTORE)
Date: Fri, 23 Aug 2013 19:34:31 -0400
Subject: RFR - 8023580 - Add jtreg test for 8004051 and 8005722
In-Reply-To: <5217DCD0.1050005@oracle.com>
References: <5216532C.3080802@oracle.com> <5217DCD0.1050005@oracle.com>
Message-ID: <5217F187.9010806@oracle.com>

On 8/23/2013 6:06 PM, Mikhailo Seledtsov wrote:
> Hi Bill,
>
>  The test looks good to me, though I am not an official Reviewer.
> One style comment: in Java tests, unlike the C/C++ code, the style 
> guideline is to use 4 spaces for tabulation/indentation.
Hi Misha,

I actually had copied/pasted from a bug report and forgot about spacing. 
I'll fix it.

thanks a lot,
bill

>
> Misha
>
> On 8/22/2013 2:06 PM, BILL PITTORE wrote:
>> Would like a review of the following test being added to 
>> hotspot/test/compiler that tests an assertion failure for both 
>> 8004051 and 8005722.
>>
>> http://cr.openjdk.java.net/~bpittore/8023580/webrev.00/
>>
>> thanks,
>> bill
>>
>>
>


From tao.mao at oracle.com  Fri Aug 23 16:46:28 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Fri, 23 Aug 2013 16:46:28 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <5217EAC4.9090001@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com>
Message-ID: <5217F454.50105@oracle.com>

Big thanks again for improving this.

Tao

On 8/23/13 4:05 PM, Yumin Qi wrote:
> Tao,
>
>   Thanks for your review.
>
> On 8/23/2013 3:33 PM, Tao Mao wrote:
>> Hi,
>>
>> I reviewed most of the code and test-ran a build from it. It's a very 
>> cool and important improvement.
>>
>> Thank you for putting together these on our wishlist for long.
>>
>> Below are some comments.
>>
>> 1. src/share/vm/runtime/arguments.cpp
>>
>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>
>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>
>> I worked on a problem of enabling gc log limit over 2G (JDK-7122222). 
>> So it seems that customers sometimes want gc logs to be very large.
>>
> Sure, will add.
Thank you.
>> 2. src/share/vm/runtime/arguments.hpp
>>
>> (1) with the current changeset, we only append date&time to file_name 
>> w/ +UseGCLogFileRotation; if not, we won't have date&time info.
>>
>> I think it would be useful to let both cases (w/ and w/o 
>> UseGCLogFileRotation) have date&time in order to solve the 
>> overwritten problem (e.g. JDK-8020667). In fact, having that, we 
>> actually solve JDK-8020667.
>>
>> If you want to have that, basically you need to work on the 
>> FileStream constructor methods fileStream().
>>
> I can change that, if no objection from others. This also will 
> simplify the setting of file name here.
Thank you. Let's see if anyone disagrees with a good reason.
>
>> (2) Would it be better to rename method name reformat_filename() to 
>> extend_filename()?
>>
>> (3) Typos and suggestion
>> 537 // rotate file in names filename.0, filename.1, ..., 
>> filename.<NumberOfGCLogFiles - 1>
>> *=> extended_filename.0*
>>
>> 538 // filename contains pid and time when the fist file created. The 
>> current filename is
>> *=> *the*first *file created.
>>
>> 539 // gc_log_file_name + pid<pid> + YYYY-MM-DD_HH-MM-SS.<i>.current, 
>> where i is current
>> 540 // rotation file number. After it reaches max file size, the file 
>> will be saved and
>> 541 // renamed with .current removed from its tail.
>>
> Will change that.
Thank you.
>> 3. For your point 5), I don't quite get it. In my test-run, I tried 
>> to change file permission to unreadable and unwritable, but VM would 
>> later change the permission back anyway.
>>
>> So could you bring up some use cases of that functionality to give 
>> more details?
>>
> Changing file permission will not stop the file create, in this 
> rotation, the file opened/saved/removed/renamed -> then repeat. What I 
> have done is change the while directory to read only, then the create 
> failed so rotation stopped.
>
So, when VM is already running and gc logs are rotating, how should I 
make the rotation stop? Let me give one more try.
>> 4. Will you write jtreg tests for this functionality? It looks 
>> possible to write some tests, at least checking the format of log names.
>>
> Good suggestion, I will add one.
You may also want to check the number of gc logs created is what we 
desire to have, when the Java process is completed.

The example in the link 
(http://stackoverflow.com/questions/5694385/getting-the-filenames-of-all-files-in-a-folder) 
basically describes a routine to list all filenames in a directory. Hope 
that helps.
>
>> Thanks.
>> Tao
>>
>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>> Could I get  a GC staff review the change? Need more reviewers to 
>>> push this in.
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>> Hi, all
>>>>
>>>>   This is second version after feedback from first round.
>>>>   The changes are:
>>>>
>>>>   1) file name will be based on gc log file name 
>>>> (-Xloggc:filename), pid (process id) and time when the first 
>>>> rotation file created:
>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>   2) If rotate in same file, file name is as in 1), if rotate in 
>>>> multiple files, .<i> will append to above file name.
>>>>   3) every time file rotated, file name and time when file created 
>>>> will be logged to head/tail, this is same as first version.
>>>>   4) current file has name 
>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>        This is similar to first version.
>>>>        By adapting such name format we will never loss logs in case 
>>>> apps stops and restart, the log files will not be overwritten since 
>>>> time stamp in file names.
>>>>    5) If open file failed, turn off gc log rotation.
>>>>         If due to some reason, file operation failed (such as 
>>>> permission changed etc), with log file opened, logging still works, 
>>>> but at
>>>>         saving and renaming, the file operation will fail, this 
>>>> will lead not all files saved.
>>>>
>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>
>>>>      Tested with jtreg, JPRT.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>> Hi,
>>>>>
>>>>>   Can I have your review for this small changes?
>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>
>>>>>    This is for a enhancement to add head/tail message to the 
>>>>> logging files to assist reading GC output.
>>>>>    1. modified prompt message if invalid arguments used for log 
>>>>> rotating;
>>>>>    2. add time and file name message to log file head/tail.
>>>>>    3. for easily identify which log file is current, use file name 
>>>>> like <filename>.n.current, after it reaches maximum size, rename 
>>>>> it to <filename>.n
>>>>>         On Windows, there is no F_OK (existing test) definition, 
>>>>> F_OK is defined as "0" and for _access of VC++, it just describes:
>>>>>
>>>>> modevalue
>>>>>
>>>>> 	
>>>>>
>>>>> Checks file for
>>>>>
>>>>> 00
>>>>>
>>>>> 	
>>>>>
>>>>> Existence only
>>>>>
>>>>> 02
>>>>>
>>>>> 	
>>>>>
>>>>> Write-only
>>>>>
>>>>> 04
>>>>>
>>>>> 	
>>>>>
>>>>> Read-only
>>>>>
>>>>> 06
>>>>>
>>>>> 	
>>>>>
>>>>> Read and write
>>>>>
>>>>>
>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>> The definition are consistent with unistd.h.
>>>>>
>>>>>     Test: JPRT and jtreg.
>>>>>
>>>>>    Thanks
>>>>>    Yumin
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130823/b459d8a7/attachment-0001.html 

From daniel.daugherty at oracle.com  Fri Aug 23 17:09:20 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Sat, 24 Aug 2013 00:09:20 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 26 new changesets
Message-ID: <20130824001012.2F05748B23@hg.openjdk.java.net>

Changeset: afbe18ae0905
Author:    bharadwaj
Date:      2013-08-15 11:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/afbe18ae0905

8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases
Summary: Corrected details
Reviewed-by: kvn, twisti, rbackman
Contributed-by: david.r.chase at oracle.com

! src/cpu/x86/vm/templateInterpreter_x86_64.cpp

Changeset: adb9a7d94cb5
Author:    adlertz
Date:      2013-08-16 10:23 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/adb9a7d94cb5

8023003: Cleanup the public interface to PhaseCFG
Summary: public methods that don't need to be public should be private.
Reviewed-by: kvn, twisti

! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 6c72125a2f40
Author:    iignatyev
Date:      2013-08-16 17:34 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6c72125a2f40

8016456: ciReplay test assumes TIERED compilation is available
Reviewed-by: vlivanov, kvn, dholmes

! test/compiler/ciReplay/common.sh

Changeset: f99558245e5c
Author:    iignatyev
Date:      2013-08-14 23:50 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f99558245e5c

8022832: Add WB APIs for OSR compilation
Reviewed-by: kvn

! src/share/vm/oops/method.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/compiler/whitebox/SetForceInlineMethodTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: d18b10b1fd09
Author:    iignatyev
Date:      2013-08-16 13:39 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d18b10b1fd09

Merge


Changeset: 4b2838704fd5
Author:    kvn
Date:      2013-08-16 14:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4b2838704fd5

8021898: Broken JIT compiler optimization for loop unswitching
Summary: fix method clone_projs() to clone all related MachProj nodes.
Reviewed-by: roland, adlertz

! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 6725044c5725
Author:    rbackman
Date:      2013-08-19 09:33 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6725044c5725

Merge

! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/oops/method.cpp

Changeset: e16282db4946
Author:    twisti
Date:      2013-08-20 10:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e16282db4946

8022956: Clang: enable return type warnings on BSD
Reviewed-by: coleenp, sla

! make/bsd/makefiles/gcc.make
! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/frame_zero.cpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/icBuffer_zero.cpp
! src/cpu/zero/vm/interp_masm_zero.hpp
! src/cpu/zero/vm/interpreter_zero.cpp
! src/cpu/zero/vm/nativeInst_zero.hpp
! src/cpu/zero/vm/register_zero.cpp
! src/cpu/zero/vm/relocInfo_zero.cpp
! src/cpu/zero/vm/sharedRuntime_zero.cpp
! src/cpu/zero/vm/vtableStubs_zero.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp

Changeset: acedd49a1bce
Author:    rbackman
Date:      2013-08-08 03:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/acedd49a1bce

8022675: Redundant class init check
Reviewed-by: kvn, twisti

! src/share/vm/opto/library_call.cpp

Changeset: 4dece0730c50
Author:    rbackman
Date:      2013-08-22 18:37 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4dece0730c50

Merge

! src/share/vm/runtime/vmStructs.cpp
! test/compiler/ciReplay/common.sh

Changeset: 5888334c9c24
Author:    johnc
Date:      2013-08-15 10:52 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5888334c9c24

7145569: G1: optimize nmethods scanning
Summary: Add a list of nmethods to the RSet for a region that contain references into the region. Skip scanning the code cache during root scanning and scan the nmethod lists during RSet scanning instead.
Reviewed-by: tschatzl, brutisso, mgerdin, twisti, kvn

! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/iterator.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/utilities/growableArray.hpp

Changeset: 8088d93a63e6
Author:    brutisso
Date:      2013-08-15 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8088d93a63e6

Merge


Changeset: 9720d338b1d5
Author:    brutisso
Date:      2013-08-16 11:26 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9720d338b1d5

8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0
Reviewed-by: stefank, mgerdin

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: d0afbee540e0
Author:    stefank
Date:      2013-08-19 13:44 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d0afbee540e0

8023227: Enhance layout_helper_log2_element_size assert
Reviewed-by: mgerdin, jmasa

! src/share/vm/oops/klass.hpp

Changeset: 422920730903
Author:    ehelin
Date:      2013-08-19 18:17 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/422920730903

8023219: NPG: MetaspaceMemoryPool should report statistics for all of metaspace
Reviewed-by: stefank, sjohanss

! src/share/vm/services/memoryPool.cpp

Changeset: 57600c4aeabe
Author:    jmasa
Date:      2013-08-19 08:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/57600c4aeabe

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 31f220c1f789
Author:    jmasa
Date:      2013-08-20 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/31f220c1f789

Merge


Changeset: 61521bd65100
Author:    tschatzl
Date:      2013-08-21 10:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/61521bd65100

8022784: TaskQueue misses minimal documentation and references for analysis
Summary: Add appropriate documentation and references to publication to allow easier analysis of the TaskQueue implementation.
Reviewed-by: dholmes, ehelin

! src/share/vm/utilities/taskqueue.hpp

Changeset: cb9da55b1990
Author:    jmasa
Date:      2013-08-14 19:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cb9da55b1990

8021809: Partitioning based on eden sampling during allocation not reset correctly
Reviewed-by: ysr, hiroshi

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: b51aee2dd8bb
Author:    jmasa
Date:      2013-08-22 11:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b51aee2dd8bb

Merge

! src/share/vm/oops/klass.hpp

Changeset: 8009adb44523
Author:    jmasa
Date:      2013-08-22 14:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8009adb44523

Merge


Changeset: c93e0a210e1b
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c93e0a210e1b

Added tag jdk8-b104 for changeset 104743074675

! .hgtags

Changeset: c1604d5885a6
Author:    amurillo
Date:      2013-08-23 03:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c1604d5885a6

Merge


Changeset: acac3bde66b2
Author:    amurillo
Date:      2013-08-23 03:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/acac3bde66b2

Added tag hs25-b47 for changeset c1604d5885a6

! .hgtags

Changeset: 73921c720b94
Author:    amurillo
Date:      2013-08-23 03:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/73921c720b94

8023635: new hotspot build - hs25-b48
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: cacc421f39d7
Author:    dcubed
Date:      2013-08-23 10:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cacc421f39d7

Merge

- test/runtime/7051189/Xchecksig.sh


From david.holmes at oracle.com  Fri Aug 23 21:02:47 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 24 Aug 2013 14:02:47 +1000
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <5217A19F.7020103@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
	<5216FBA9.50807@oracle.com> <5217072C.5020106@oracle.com>
	<5217A19F.7020103@oracle.com>
Message-ID: <52183067.8000600@oracle.com>

On 24/08/2013 3:53 AM, Calvin Cheung wrote:

 > I've just noticed that there's a slight error in my change in line #325
 > of classLoader.cpp:
 >
 > ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
 >
 > should be
 >
 > ClassPathEntry* cpe = resolve_entry(THREAD);
 >
 > Otherwise, it'll skip the rest of the statements.

Which is exactly the problem I was flagging. :)

David
-----

> On 8/22/2013 11:54 PM, David Holmes wrote:
>> On 23/08/2013 4:05 PM, Calvin Cheung wrote:
>>> On 8/22/2013 5:21 PM, David Holmes wrote:
>>>> Hi Calvin,
>>>>
>>>> I'm having trouble keeping track of this one ...
>>>>
>>>> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>>>>> Note that the synopsis of the bug has been changed from:
>>>>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0
>>>>> Build 4"
>>>>>
>>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>>>>
>>>>> I've included the suggestions from Coleen and Ioi in this version of
>>>>> webrev:
>>>>>      http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>
>>>> I don't understand your _has_error logic:
>>>>
>>>>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>>  326   if (cpe == NULL) {
>>>>  327     _has_error = true;
>>>>  328     return NULL;
>>>>
>>>> we will only hit line 327 if resolve_entry returns NULL _without_
>>>> there being an exception pending. How does that occur? What is
>>>> different about the two cases regardless?
>>> The _has_error flag was suggested by Ioi and is to avoid opening the
>>> invalid jar file again.
>>
>> Can't we just remove it from the classpath representation?
> I think it can be done if the error happens during vm initialization.
> But for this test scenario, the error happens after vm init.
> Perhaps this should be addressed as a separate bug fix?
>>
>>> The call sequence is as follows:
>>> ClassLoader::load_classfile()
>>>      -> LazyClassPathEntry::open_stream()
>>>          -> LazyClassPathEntry::resolve_entry()
>>>              -> ClassLoader::create_class_path_entry()
>>>
>>> For second time, it'll return NULL without calling resolve_entry()
>>> again.
>>>
>>> The LazyClassPathEntry instance is instantiated by the following calls:
>>> ClassLoader::setup_bootstrap_search_path()
>>>      ->ClassLoader::update_class_path_entry_list()
>>>          ->ClassLoader::create_class_path_entry(path, &st,
>>> LazyBootClassLoader, CHECK)
>>>
>>> LazyBootClassLoader is set to true by default.
>>
>> Sorry but I don't see how that answers my question. Based on the below
>> there isn't a second time because the first time will cause the
>> pending exception which will terminate the VM. Even if we dont
>> terminate and somehow call this again, we didn't set _has_error the
>> first time anyway! ???
> Let's not confused with the classes we're preloading during vm
> initialization and the applications classes after vm initialization.
>
> Consider the following test case:
> public class test3 {
>      public static void main(String[] args) {
>          try {
>              //Class cls = Class.forName("javax.crypto.KeyGenerator");
>              //System.out.println("Class = " + cls.getName());
>              Class cls = Class.forName("xxx");
>              System.out.println("Class = " + cls.getName());
>          } catch (ClassNotFoundException cnfe) {
>              cnfe.printStackTrace();
>          }
>          try {
>              Class cls2 = Class.forName("yyy");
>              System.out.println("Class = " + cls2.getName());
>          } catch (ClassNotFoundException cnfe) {
>              cnfe.printStackTrace();
>          }
>      }
> }
>
> Let's say we have a dummy.jar with 0-byte and test3.class in the same
> directory.
> And command line as follows:
> java -Xbootclasspath/a:dummy.jar -cp . test3
>
> During vm init. (as in the above
> ClassLoader::setup_bootstrap_search_path() call sequence), there's no
> problem because vm doesn't need to read dummy.jar as all other preload
> classes can be found in jdk's jar files (rt.jar, jce.jar, etc.) (Note:
> this isn't the case with 7u25, we were trying to preload a non-existing
> class, please refer to my comment in the bug report.)
>
> When vm tries to load the class for the test case (test3.class), it'll
> call into LazyClassPathEntry::open_stream(). This is the first time
> resolve_entry() returns NULL and the _has_error flag will be set to
> true. The next time vm will try to load xxx.class. Since _has_error was
> set to NULL, it will return NULL without calling resolve_entry(). Same
> story for the third time for the yyy.class.
>
> call stack as follows:
>       jvm.dll!ClassLoader::create_class_path_entry(char * path, const
> stat * st, bool lazy, Thread * __the_thread__)  Line 515    C++
>       jvm.dll!LazyClassPathEntry::resolve_entry(Thread *
> __the_thread__)  Line 304 + 0x19 bytes    C++
>       jvm.dll!LazyClassPathEntry::open_stream(const char * name, Thread
> * __the_thread__)  Line 325 + 0xc bytes    C++
>       jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread *
> __the_thread__)  Line 909 + 0x1b bytes    C++
>       jvm.dll!SystemDictionary::load_instance_class(Symbol * class_name,
> Handle class_loader, Thread * __the_thread__)  Line 1301 + 0x14 bytes
> C++
>       jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol *
> name, Handle class_loader, Handle protection_domain, Thread *
> __the_thread__)  Line 779 + 0x18 bytes    C++
>       jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name,
> Handle class_loader, Handle protection_domain, Thread * __the_thread__)
> Line 232 + 0x15 bytes    C++
>       jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name,
> Thread * __the_thread__)  Line 237 + 0x23 bytes    C++
>  >    jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char *
> name)  Line 770 + 0x12 bytes    C++
>       java.dll!70671e8c()
>
> I've just noticed that there's a slight error in my change in line #325
> of classLoader.cpp:
>
> ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>
> should be
>
> ClassPathEntry* cpe = resolve_entry(THREAD);
>
> Otherwise, it'll skip the rest of the statements.
> I'll update webrev shortly.
>
>>
>>>>
>>>> And we still have this sequence:
>>>>
>>>> void ClassLoader::initialize() {
>>>>   assert(_package_hash_table == NULL, "should have been initialized by
>>>> now.");
>>>>   EXCEPTION_MARK;
>>>>   ...
>>>>   setup_bootstrap_search_path();
>>>>     -> update_class_path_entry_list(path, false);
>>>>       ->  create_class_path_entry((char *)path, st, &new_entry,
>>>> LazyBootClassLoader, CHECK);
>>> As mentioned above, this call sequence is for instantiating the
>>> LazyClassPathEntry instances.
>>>>
>>>> So if we return after the call to create_class_path_entry with an
>>>> exception pending we will crash when we hit the EXCEPTION_MARK. Why
>>>> doesn't this happen?
>>> During vm initilization, it's ok to have exception pending. The
>>> destructor of ExceptionMark is as follows:
>>> ExceptionMark::~ExceptionMark() {
>>>    if (_thread->has_pending_exception()) {
>>>      Handle exception(_thread, _thread->pending_exception());
>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>> recursion
>>>      if (is_init_completed()) {
>>>        exception->print();
>>>        fatal("ExceptionMark destructor expects no pending exceptions");
>>>      } else {
>>>        vm_exit_during_initialization(exception);
>>>      }
>>>    }
>>> }
>>>
>>> So if is_init_completed() is false, it'll just print an error and exit.
>>
>> So we do hit it - ok. So this yet another place where the VM should
>> not abort during initialization.
> Yes and this is for preloading class scenario during vm init.
> IMHO, I don't think we should change the behavior now.
>
> thanks,
> Calvin
>>
>> Thanks,
>> David
>>
>>> thanks,
>>> Calvin
>>>
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>> Tests:
>>>>>      jprt
>>>>>          (in progress - only about 30 tests left on the windows
>>>>> platforms, no failure so far;
>>>>>           a previous run with only Coleen's suggestions was
>>>>> successful)
>>>>>
>>>>>      vm.quick.testlist on linux_x64
>>>>>
>>>>> Please review.
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>
>

From david.simms at oracle.com  Sun Aug 25 02:16:17 2013
From: david.simms at oracle.com (David Simms)
Date: Sun, 25 Aug 2013 11:16:17 +0200
Subject: RFR (S): 8022683 : JNI GetStringUTFChars should return NULL on
	allocation failure not abort the VM
In-Reply-To: <5217A968.4070702@oracle.com>
References: <520E3B16.2040100@oracle.com> <52119635.1050908@oracle.com>
	<521496C5.6020805@oracle.com> <5217A968.4070702@oracle.com>
Message-ID: <5219CB61.6000002@oracle.com>


Thanks for the review !

On 08/23/2013 08:26 PM, Coleen Phillimore wrote:
>
> DavidS,
>
> I think this change looks good.  Going from a vm_exit_out_of_memory() 
> in JVM to dtrace (sdt probes on some linuxes) not providing 
> information, which it couldn't before with a crash, is still an 
> improvement.
>
> Coleen
>
> On 8/21/2013 6:30 AM, David Simms wrote:
>>
>> Been a little side-track, reply inline...
>>
>> On 19/08/13 05:51, David Holmes wrote:
>>> Hi David,
>>>
>>> On 17/08/2013 12:45 AM, David Simms wrote:
>>>> Hello all,
>>>>
>>>> Need reviewers on a JDK8 fix for:
>>>> http://bugs.sun.com/view_bug.do?bug_id=8022683
>>>>
>>>> Found the following functions need to return NULL as suggested by the
>>>> JNI spec
>>>> (http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html): 
>>>>
>>>>
>>>>   * GetStringChars()
>>>>   * GetStringUTFChars()
>>>>   * Get<PrimitiveType>ArrayElements() family of array getters (same
>>>>     generating macro).
>>>>
>>>> Although the specification suggests OOME may be thrown by certain
>>>> functions, the documentation on the aforementioned functions does not
>>>> suggest "throws". So they return NULL now without aborting the JVM as
>>>> before.
>>>
>>> There is always come contention with the JNI spec as to whether the 
>>> intent is as defined by the original JNI spec book, or whether it is 
>>> reflected in what is considered the "official spec". :)
>>>
>> Agreed, but let's just take the documentation developers have to go on.
>>>> It was assumed the meaning of "isCopy" is undefined given a NULL 
>>>> result,
>>>> in keeping with the rest of jni.cpp.
>>>
>>> Even so I think it preferable to not set it unless the operation 
>>> succeeds.
>>>
>> Done
>>>> Also discovered allocation.hpp macros missing proper argument 
>>>> bracketing
>>>> (e.g. size passed in NEW_C_HEAP_ARRAY_RETURN_NULL()), fixed them up
>>>> since I was there (and they caused trouble).
>>>
>>> I can only see size causing a problem because it is used in an 
>>> expression. The rest seems somewhat overkill.
>>>
>> Fine, no need to get too happy, also done.
>>
>>     Been used to as a matter of practice bracketing anything
>>     involving possible expression/calculation, i.e. pointer math.
>>
>> Updated webrev:
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dsimms/8022683/
>>>> <http://cr.openjdk.java.net/%7Edsimms/8022683/>
>>>
>>> One concern I have is in how the dtrace probes will handle things if 
>>> buf/result is NULL?
>> Previous behavior was to exit the vm with OOM error (i.e.: 
>> vm_exit_out_of_memory()), which dtrace doesn't handle (so we are good).
>>
>> Begs the question, how many applications will now simply crash within 
>> their native code, and does this change reduce the amount of 
>> diagnostics information. Whilst I prefer to stick the API 
>> documentation, wondering if this will be practical...  Okay tested 
>> with -Xcheck:jni which catches the problem (so we are good).
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Testing:
>>>>
>>>> Attached "unit test" to bug, naive test program to trigger OOM. It is
>>>> not suitable for automated testing. Ideally require hooks into the JVM
>>>> to simulate OOM during JNI calls.
>>>>
>>>> Cheers
>>>> /David Simms
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130825/bdb4d1f7/attachment.html 

From david.simms at oracle.com  Sun Aug 25 02:21:14 2013
From: david.simms at oracle.com (David Simms)
Date: Sun, 25 Aug 2013 11:21:14 +0200
Subject: RFR (S): 8022683 : JNI GetStringUTFChars should return NULL on
	allocation failure not abort the VM
In-Reply-To: <52149AD6.7050606@oracle.com>
References: <520E3B16.2040100@oracle.com> <52119635.1050908@oracle.com>
	<521496C5.6020805@oracle.com> <52149AD6.7050606@oracle.com>
Message-ID: <5219CC8A.2070306@oracle.com>


Hi David,

So I've tested with dtrace both "by hand" with probes enabled and 
scripting and using the test list (faked OOM and NULL return). No 
problems encountered. Assume we are good, thanks for the review !

/Simms

On 08/21/2013 12:47 PM, David Holmes wrote:
> On 21/08/2013 8:30 PM, David Simms wrote:
>>
>> Been a little side-track, reply inline...
>>
>> On 19/08/13 05:51, David Holmes wrote:
>>> Hi David,
>>>
>>> On 17/08/2013 12:45 AM, David Simms wrote:
>>>> Hello all,
>>>>
>>>> Need reviewers on a JDK8 fix for:
>>>> http://bugs.sun.com/view_bug.do?bug_id=8022683
>>>>
>>>> Found the following functions need to return NULL as suggested by the
>>>> JNI spec
>>>> (http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html): 
>>>>
>>>>
>>>>
>>>>   * GetStringChars()
>>>>   * GetStringUTFChars()
>>>>   * Get<PrimitiveType>ArrayElements() family of array getters (same
>>>>     generating macro).
>>>>
>>>> Although the specification suggests OOME may be thrown by certain
>>>> functions, the documentation on the aforementioned functions does not
>>>> suggest "throws". So they return NULL now without aborting the JVM as
>>>> before.
>>>
>>> There is always come contention with the JNI spec as to whether the
>>> intent is as defined by the original JNI spec book, or whether it is
>>> reflected in what is considered the "official spec". :)
>>>
>> Agreed, but let's just take the documentation developers have to go on.
>>>> It was assumed the meaning of "isCopy" is undefined given a NULL 
>>>> result,
>>>> in keeping with the rest of jni.cpp.
>>>
>>> Even so I think it preferable to not set it unless the operation
>>> succeeds.
>>>
>> Done
>>>> Also discovered allocation.hpp macros missing proper argument 
>>>> bracketing
>>>> (e.g. size passed in NEW_C_HEAP_ARRAY_RETURN_NULL()), fixed them up
>>>> since I was there (and they caused trouble).
>>>
>>> I can only see size causing a problem because it is used in an
>>> expression. The rest seems somewhat overkill.
>>>
>> Fine, no need to get too happy, also done.
>>
>>     Been used to as a matter of practice bracketing anything involving
>>     possible expression/calculation, i.e. pointer math.
>>
>> Updated webrev:
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dsimms/8022683/
>>>> <http://cr.openjdk.java.net/%7Edsimms/8022683/>
>>>
>>> One concern I have is in how the dtrace probes will handle things if
>>> buf/result is NULL?
>> Previous behavior was to exit the vm with OOM error (i.e.:
>> vm_exit_out_of_memory()), which dtrace doesn't handle (so we are good).
>
> My concern is, if the dtrace probes see a NULL will that cause them to 
> crash or will they handle the NULL okay?
>
>> Begs the question, how many applications will now simply crash within
>> their native code, and does this change reduce the amount of diagnostics
>> information. Whilst I prefer to stick the API documentation, wondering
>> if this will be practical...  Okay tested with -Xcheck:jni which catches
>> the problem (so we are good).
>
> What did Xcheck:jni catch? Subsequent attempted use of the NULL in a 
> JNI call? I would hope so. But if the application code doesn't check 
> for NULL then it could still crash before the next JNI call.
>
> This is always a risk with making behaviour compliant with spec. I 
> think the risk is low because if we have exhausted C heap then the VM 
> is about to die at any moment anyway. But we could add a release note 
> to document this.
>
> Thanks,
> David
>
>>>
>>> Thanks,
>>> David
>>>
>>>> Testing:
>>>>
>>>> Attached "unit test" to bug, naive test program to trigger OOM. It is
>>>> not suitable for automated testing. Ideally require hooks into the JVM
>>>> to simulate OOM during JNI calls.
>>>>
>>>> Cheers
>>>> /David Simms
>>


From harold.seigel at oracle.com  Sun Aug 25 20:21:01 2013
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Mon, 26 Aug 2013 03:21:01 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022183: GCC 4.6 change sdefault setting
	for omit-frame-pointer which breaks hotspot stack walking
Message-ID: <20130826032103.669BB48B48@hg.openjdk.java.net>

Changeset: badf4244ceae
Author:    hseigel
Date:      2013-08-25 21:21 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/badf4244ceae

8022183: GCC 4.6 change sdefault setting for omit-frame-pointer which breaks hotspot stack walking
Summary: Explicitly specify -fno-omit-frame-pointer.
Reviewed-by: coleenp, dholmes, dcubed

! make/linux/makefiles/amd64.make
! make/linux/makefiles/gcc.make


From david.holmes at oracle.com  Sun Aug 25 21:34:45 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 26 Aug 2013 14:34:45 +1000
Subject: RFR (S): 8022683 : JNI GetStringUTFChars should return NULL on
	allocation failure not abort the VM
In-Reply-To: <5219CC8A.2070306@oracle.com>
References: <520E3B16.2040100@oracle.com> <52119635.1050908@oracle.com>
	<521496C5.6020805@oracle.com> <52149AD6.7050606@oracle.com>
	<5219CC8A.2070306@oracle.com>
Message-ID: <521ADAE5.30104@oracle.com>

On 25/08/2013 7:21 PM, David Simms wrote:
>
> Hi David,
>
> So I've tested with dtrace both "by hand" with probes enabled and
> scripting and using the test list (faked OOM and NULL return). No
> problems encountered. Assume we are good, thanks for the review !

Great! Thanks for checking that out.

David

> /Simms
>
> On 08/21/2013 12:47 PM, David Holmes wrote:
>> On 21/08/2013 8:30 PM, David Simms wrote:
>>>
>>> Been a little side-track, reply inline...
>>>
>>> On 19/08/13 05:51, David Holmes wrote:
>>>> Hi David,
>>>>
>>>> On 17/08/2013 12:45 AM, David Simms wrote:
>>>>> Hello all,
>>>>>
>>>>> Need reviewers on a JDK8 fix for:
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8022683
>>>>>
>>>>> Found the following functions need to return NULL as suggested by the
>>>>> JNI spec
>>>>> (http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html):
>>>>>
>>>>>
>>>>>
>>>>>   * GetStringChars()
>>>>>   * GetStringUTFChars()
>>>>>   * Get<PrimitiveType>ArrayElements() family of array getters (same
>>>>>     generating macro).
>>>>>
>>>>> Although the specification suggests OOME may be thrown by certain
>>>>> functions, the documentation on the aforementioned functions does not
>>>>> suggest "throws". So they return NULL now without aborting the JVM as
>>>>> before.
>>>>
>>>> There is always come contention with the JNI spec as to whether the
>>>> intent is as defined by the original JNI spec book, or whether it is
>>>> reflected in what is considered the "official spec". :)
>>>>
>>> Agreed, but let's just take the documentation developers have to go on.
>>>>> It was assumed the meaning of "isCopy" is undefined given a NULL
>>>>> result,
>>>>> in keeping with the rest of jni.cpp.
>>>>
>>>> Even so I think it preferable to not set it unless the operation
>>>> succeeds.
>>>>
>>> Done
>>>>> Also discovered allocation.hpp macros missing proper argument
>>>>> bracketing
>>>>> (e.g. size passed in NEW_C_HEAP_ARRAY_RETURN_NULL()), fixed them up
>>>>> since I was there (and they caused trouble).
>>>>
>>>> I can only see size causing a problem because it is used in an
>>>> expression. The rest seems somewhat overkill.
>>>>
>>> Fine, no need to get too happy, also done.
>>>
>>>     Been used to as a matter of practice bracketing anything involving
>>>     possible expression/calculation, i.e. pointer math.
>>>
>>> Updated webrev:
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~dsimms/8022683/
>>>>> <http://cr.openjdk.java.net/%7Edsimms/8022683/>
>>>>
>>>> One concern I have is in how the dtrace probes will handle things if
>>>> buf/result is NULL?
>>> Previous behavior was to exit the vm with OOM error (i.e.:
>>> vm_exit_out_of_memory()), which dtrace doesn't handle (so we are good).
>>
>> My concern is, if the dtrace probes see a NULL will that cause them to
>> crash or will they handle the NULL okay?
>>
>>> Begs the question, how many applications will now simply crash within
>>> their native code, and does this change reduce the amount of diagnostics
>>> information. Whilst I prefer to stick the API documentation, wondering
>>> if this will be practical...  Okay tested with -Xcheck:jni which catches
>>> the problem (so we are good).
>>
>> What did Xcheck:jni catch? Subsequent attempted use of the NULL in a
>> JNI call? I would hope so. But if the application code doesn't check
>> for NULL then it could still crash before the next JNI call.
>>
>> This is always a risk with making behaviour compliant with spec. I
>> think the risk is low because if we have exhausted C heap then the VM
>> is about to die at any moment anyway. But we could add a release note
>> to document this.
>>
>> Thanks,
>> David
>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Testing:
>>>>>
>>>>> Attached "unit test" to bug, naive test program to trigger OOM. It is
>>>>> not suitable for automated testing. Ideally require hooks into the JVM
>>>>> to simulate OOM during JNI calls.
>>>>>
>>>>> Cheers
>>>>> /David Simms
>>>
>

From staffan.larsen at oracle.com  Mon Aug 26 01:13:19 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 26 Aug 2013 10:13:19 +0200
Subject: Request for review:8023477: Invalid CP index when reading
	ConstantPool
In-Reply-To: <5217D8FE.9090507@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
	<52169BDF.1090800@oracle.com>
	<4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>
	<52177DE5.9040701@oracle.com> <5217A327.2080506@oracle.com>
	<5217D8FE.9090507@oracle.com>
Message-ID: <D370EE38-9400-4C14-A32F-B1F5E62FA7EF@oracle.com>

Looks good.

Thanks,
/Staffan

On 23 aug 2013, at 23:49, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:

> Hi,
> 
> Please review the fix for 8023477:
> 
>  http://cr.openjdk.java.net/~jiangli/8023477/webrev.00/
> 
> Both tests reported by the bug failed due to the same problem. They both are passing now.
> 
> The original memory reduction change for 8021948 turned out to be a little trickier than I expected.
> 
> Thanks,
> Jiangli
> 
> 
> On 08/23/2013 11:00 AM, Jiangli Zhou wrote:
>> I found the issue in the SA code. For class without generic signature, the InstanceKlass::_generic_signature_index is 0. Need to check for this case in the SA code. I'm working on the fix and doing testing.
>> 
>> Thanks,
>> Jiangli
>> 
>> On 08/23/2013 08:21 AM, Jiangli Zhou wrote:
>>> Hi Staffan,
>>> 
>>> Thanks for the info. Will look into that one.
>>> 
>>> Jiangli
>>> 
>>> On 08/23/2013 05:27 AM, Staffan Larsen wrote:
>>>> Unfortunately there are two more tests that started failing after the initial change. See: JDK-8023477.
>>>> 
>>>> /Staffan
>>>> 
>>>> On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>>>> 
>>>>> Hi Coleen,
>>>>> 
>>>>> Yes, that's the case. Thanks for the review. I'll push this to hotspot-rt.
>>>>> 
>>>>> Thanks,
>>>>> Jiangli
>>>>> 
>>>>> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>>>>>> Hi,
>>>>>> Is it the case that the old index isn't in the index map because it didn't change?  If so, this looks correct.
>>>>>> Thanks,
>>>>>> Coleen
>>>>>> 
>>>>>> 
>>>>>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>>>>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Hi Jiangli,
>>>>>>>> 
>>>>>>>> The fix is good and safe.
>>>>>>>> I'm happy you fixed another case as well!
>>>>>>>> Let's consider current bug as a clean-up issue so that we do not need to file a separate bug. :)
>>>>>>> Ok.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Jiangli
>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>>>>>> Hi Serguei,
>>>>>>>>> 
>>>>>>>>> I've also made change to the case that you discovered. Please let me know if you think a separate bug should be filed to track it instead.
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Jiangli
>>>>>>>>> 
>>>>>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>>>>>> Hi Serguei,
>>>>>>>>>> 
>>>>>>>>>> Thank you very much for the review and confirmation with the test.
>>>>>>>>>> 
>>>>>>>>>> Jiangli
>>>>>>>>>> 
>>>>>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>> Hi Jiangli,
>>>>>>>>>>> 
>>>>>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>>>>>> I confirm the test is passed with it.
>>>>>>>>>>> 
>>>>>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>>>>>> I've noticed the following fragment in this file which seems has a similar issue:
>>>>>>>>>>> 
>>>>>>>>>>>  // We also need to rewrite the parameter name indexes, if there is
>>>>>>>>>>>  // method parameter data present
>>>>>>>>>>>  if(method->has_method_parameters()) {
>>>>>>>>>>>    const int len = method->method_parameters_length();
>>>>>>>>>>>    MethodParametersElement* elem = method->method_parameters_start();
>>>>>>>>>>> 
>>>>>>>>>>>    for (int i = 0; i < len; i++) {
>>>>>>>>>>>      const u2 cp_index = elem[i].name_cp_index;
>>>>>>>>>>>      elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>>>>>    }
>>>>>>>>>>>  }
>>>>>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>>>>>> 
>>>>>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Serguei
>>>>>>>>>>> 
>>>>>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>>>>>> 
>>>>>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>>>>>> 
>>>>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> 
>>>>>>>>>>>> Jiangli
>>> 
>> 
> 


From bengt.rutisson at oracle.com  Mon Aug 26 04:47:13 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 26 Aug 2013 13:47:13 +0200
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <5217EAC4.9090001@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com>
Message-ID: <521B4041.5050300@oracle.com>


Hi Yumin and Tao,

I have not reviewed the code change but I have a comment inlined below.

On 8/24/13 1:05 AM, Yumin Qi wrote:
> Tao,
>
>   Thanks for your review.
>
> On 8/23/2013 3:33 PM, Tao Mao wrote:
>> Hi,
>>
>> I reviewed most of the code and test-ran a build from it. It's a very 
>> cool and important improvement.
>>
>> Thank you for putting together these on our wishlist for long.
>>
>> Below are some comments.
>>
>> 1. src/share/vm/runtime/arguments.cpp
>>
>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>
>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>
>> I worked on a problem of enabling gc log limit over 2G (JDK-7122222). 
>> So it seems that customers sometimes want gc logs to be very large.
>>
> Sure, will add.
>> 2. src/share/vm/runtime/arguments.hpp
>>
>> (1) with the current changeset, we only append date&time to file_name 
>> w/ +UseGCLogFileRotation; if not, we won't have date&time info.
>>
>> I think it would be useful to let both cases (w/ and w/o 
>> UseGCLogFileRotation) have date&time in order to solve the 
>> overwritten problem (e.g. JDK-8020667). In fact, having that, we 
>> actually solve JDK-8020667.
>>
>> If you want to have that, basically you need to work on the 
>> FileStream constructor methods fileStream().
>>
> I can change that, if no objection from others. This also will 
> simplify the setting of file name here.

I think appending a timestamp to the log file name is a nice idea, but I 
think it is also a bit scary. There are users who restart their 
applications regularly. With the suggested idea such users will now risk 
filling up their disk space with log files. I imagine that that will not 
be appreciated by everyone. Such a change should probably be discussed 
more thoroughly than just in a review request.

Thanks,
Bengt


>
>> (2) Would it be better to rename method name reformat_filename() to 
>> extend_filename()?
>>
>> (3) Typos and suggestion
>> 537 // rotate file in names filename.0, filename.1, ..., 
>> filename.<NumberOfGCLogFiles - 1>
>> *=> extended_filename.0*
>>
>> 538 // filename contains pid and time when the fist file created. The 
>> current filename is
>> *=> *the*first *file created.
>>
>> 539 // gc_log_file_name + pid<pid> + YYYY-MM-DD_HH-MM-SS.<i>.current, 
>> where i is current
>> 540 // rotation file number. After it reaches max file size, the file 
>> will be saved and
>> 541 // renamed with .current removed from its tail.
>>
> Will change that.
>> 3. For your point 5), I don't quite get it. In my test-run, I tried 
>> to change file permission to unreadable and unwritable, but VM would 
>> later change the permission back anyway.
>>
>> So could you bring up some use cases of that functionality to give 
>> more details?
>>
> Changing file permission will not stop the file create, in this 
> rotation, the file opened/saved/removed/renamed -> then repeat. What I 
> have done is change the while directory to read only, then the create 
> failed so rotation stopped.
>
>> 4. Will you write jtreg tests for this functionality? It looks 
>> possible to write some tests, at least checking the format of log names.
>>
> Good suggestion, I will add one.
>
>> Thanks.
>> Tao
>>
>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>> Could I get  a GC staff review the change? Need more reviewers to 
>>> push this in.
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>> Hi, all
>>>>
>>>>   This is second version after feedback from first round.
>>>>   The changes are:
>>>>
>>>>   1) file name will be based on gc log file name 
>>>> (-Xloggc:filename), pid (process id) and time when the first 
>>>> rotation file created:
>>>>        <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>   2) If rotate in same file, file name is as in 1), if rotate in 
>>>> multiple files, .<i> will append to above file name.
>>>>   3) every time file rotated, file name and time when file created 
>>>> will be logged to head/tail, this is same as first version.
>>>>   4) current file has name 
>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>        This is similar to first version.
>>>>        By adapting such name format we will never loss logs in case 
>>>> apps stops and restart, the log files will not be overwritten since 
>>>> time stamp in file names.
>>>>    5) If open file failed, turn off gc log rotation.
>>>>         If due to some reason, file operation failed (such as 
>>>> permission changed etc), with log file opened, logging still works, 
>>>> but at
>>>>         saving and renaming, the file operation will fail, this 
>>>> will lead not all files saved.
>>>>
>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>
>>>>      Tested with jtreg, JPRT.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>> Hi,
>>>>>
>>>>>   Can I have your review for this small changes?
>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>
>>>>>    This is for a enhancement to add head/tail message to the 
>>>>> logging files to assist reading GC output.
>>>>>    1. modified prompt message if invalid arguments used for log 
>>>>> rotating;
>>>>>    2. add time and file name message to log file head/tail.
>>>>>    3. for easily identify which log file is current, use file name 
>>>>> like <filename>.n.current, after it reaches maximum size, rename 
>>>>> it to <filename>.n
>>>>>         On Windows, there is no F_OK (existing test) definition, 
>>>>> F_OK is defined as "0" and for _access of VC++, it just describes:
>>>>>
>>>>> modevalue
>>>>>
>>>>>
>>>>>
>>>>> Checks file for
>>>>>
>>>>> 00
>>>>>
>>>>>
>>>>>
>>>>> Existence only
>>>>>
>>>>> 02
>>>>>
>>>>>
>>>>>
>>>>> Write-only
>>>>>
>>>>> 04
>>>>>
>>>>>
>>>>>
>>>>> Read-only
>>>>>
>>>>> 06
>>>>>
>>>>>
>>>>>
>>>>> Read and write
>>>>>
>>>>>
>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>> The definition are consistent with unistd.h.
>>>>>
>>>>>     Test: JPRT and jtreg.
>>>>>
>>>>>    Thanks
>>>>>    Yumin
>>>>
>>>
>
>


From coleen.phillimore at oracle.com  Mon Aug 26 04:56:59 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 26 Aug 2013 07:56:59 -0400
Subject: Request for review:8023477: Invalid CP index when reading
	ConstantPool
In-Reply-To: <5217D8FE.9090507@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
	<52169BDF.1090800@oracle.com>
	<4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>
	<52177DE5.9040701@oracle.com> <5217A327.2080506@oracle.com>
	<5217D8FE.9090507@oracle.com>
Message-ID: <521B428B.20101@oracle.com>


Why doesn't

getConstants().getSymbolAt(index)

return null for index = 0 without this check?   The constant pool value 
at index 0 should be null.

Coleen

On 8/23/2013 5:49 PM, Jiangli Zhou wrote:
> Hi,
>
> Please review the fix for 8023477:
>
>   http://cr.openjdk.java.net/~jiangli/8023477/webrev.00/
>
> Both tests reported by the bug failed due to the same problem. They 
> both are passing now.
>
> The original memory reduction change for 8021948 turned out to be a 
> little trickier than I expected.
>
> Thanks,
> Jiangli
>
>
> On 08/23/2013 11:00 AM, Jiangli Zhou wrote:
>> I found the issue in the SA code. For class without generic 
>> signature, the InstanceKlass::_generic_signature_index is 0. Need to 
>> check for this case in the SA code. I'm working on the fix and doing 
>> testing.
>>
>> Thanks,
>> Jiangli
>>
>> On 08/23/2013 08:21 AM, Jiangli Zhou wrote:
>>> Hi Staffan,
>>>
>>> Thanks for the info. Will look into that one.
>>>
>>> Jiangli
>>>
>>> On 08/23/2013 05:27 AM, Staffan Larsen wrote:
>>>> Unfortunately there are two more tests that started failing after 
>>>> the initial change. See: JDK-8023477.
>>>>
>>>> /Staffan
>>>>
>>>> On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> 
>>>> wrote:
>>>>
>>>>> Hi Coleen,
>>>>>
>>>>> Yes, that's the case. Thanks for the review. I'll push this to 
>>>>> hotspot-rt.
>>>>>
>>>>> Thanks,
>>>>> Jiangli
>>>>>
>>>>> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>>>>>> Hi,
>>>>>> Is it the case that the old index isn't in the index map because 
>>>>>> it didn't change?  If so, this looks correct.
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>>
>>>>>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>>>>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Hi Jiangli,
>>>>>>>>
>>>>>>>> The fix is good and safe.
>>>>>>>> I'm happy you fixed another case as well!
>>>>>>>> Let's consider current bug as a clean-up issue so that we do 
>>>>>>>> not need to file a separate bug. :)
>>>>>>> Ok.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jiangli
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>>>>>> Hi Serguei,
>>>>>>>>>
>>>>>>>>> I've also made change to the case that you discovered. Please 
>>>>>>>>> let me know if you think a separate bug should be filed to 
>>>>>>>>> track it instead.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jiangli
>>>>>>>>>
>>>>>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>>>>>> Hi Serguei,
>>>>>>>>>>
>>>>>>>>>> Thank you very much for the review and confirmation with the 
>>>>>>>>>> test.
>>>>>>>>>>
>>>>>>>>>> Jiangli
>>>>>>>>>>
>>>>>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>> Hi Jiangli,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>>>>>> I confirm the test is passed with it.
>>>>>>>>>>>
>>>>>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>>>>>> I've noticed the following fragment in this file which seems 
>>>>>>>>>>> has a similar issue:
>>>>>>>>>>>
>>>>>>>>>>>   // We also need to rewrite the parameter name indexes, if 
>>>>>>>>>>> there is
>>>>>>>>>>>   // method parameter data present
>>>>>>>>>>>   if(method->has_method_parameters()) {
>>>>>>>>>>>     const int len = method->method_parameters_length();
>>>>>>>>>>>     MethodParametersElement* elem = 
>>>>>>>>>>> method->method_parameters_start();
>>>>>>>>>>>
>>>>>>>>>>>     for (int i = 0; i < len; i++) {
>>>>>>>>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>>>>>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>>>>>     }
>>>>>>>>>>>   }
>>>>>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>>>>>>
>>>>>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Serguei
>>>>>>>>>>>
>>>>>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> Jiangli
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/1f168bf2/attachment-0001.html 

From aleksey.shipilev at oracle.com  Mon Aug 26 05:07:26 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 26 Aug 2013 16:07:26 +0400
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <5217A48A.3020000@oracle.com>
References: <52174654.8020400@oracle.com> <5217A0FF.1040406@oracle.com>
	<5217A48A.3020000@oracle.com>
Message-ID: <521B44FE.5050805@oracle.com>

Thanks Mikhailo and Collen for review!

-Aleksey.

On 08/23/2013 10:06 PM, Mikhailo Seledtsov wrote:
> Hi Aleksey,
> 
>  Test looks good.
> 
> Misha
> 
> On 8/23/2013 1:50 PM, Coleen Phillimore wrote:
>>
>> This looks good.
>> Thanks,
>> Coleen
>>
>> On 8/23/2013 7:24 AM, Aleksey Shipilev wrote:
>>> Hi,
>>>
>>> The latest bug scrub identified one of the issues lacking the regression
>>> test, where it does make sense to create one.
>>>
>>> Background: -XX:ContendedPaddingWidth=# is range-checked on VM side to
>>> be in [0; 8192], plus being the multiple of 8. The test checks multiple
>>> values around the failure point.
>>>
>>> Here's the webrev:
>>>    http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>>>
>>> Testing:
>>>    - this test is trivial, and excersises the common code path in VM,
>>> hence only Linux x86_64/release was tested.
>>>
>>> Please review!
>>>
>>> Thanks,
>>> -Aleksey.
>>
> 


From aleksey.shipilev at oracle.com  Mon Aug 26 06:12:46 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 26 Aug 2013 17:12:46 +0400
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <5217C296.7070807@oracle.com>
References: <52174654.8020400@oracle.com> <5217C296.7070807@oracle.com>
Message-ID: <521B544E.6090201@oracle.com>

Hi Dan,

On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>
>> Here's the webrev:
>>    http://cr.openjdk.java.net/~shade/8023638/webrev.00/
> 
> hotspot/test/runtime/contended/Options.java
>     I count 11 Java process invocations. Will the default timeout
>     of 120 seconds be enough for a fastdebug '-server -Xcomp'
>     run on something like Solaris SPARC.

Linux i5/x86_64 laptop passes this test in 5 seconds. I think there is
enough headroom for slower machines.

>     The fragments:
> 
>         "must be the between"
>         "must be the multiple of 8"
> 
>     probably match the real error messages, but those messages
>     aren't quite proper English. I expected:
> 
>         "must be in between"
>         "must be a multiple of 8"

Yes. Unfortunately, this is what VM outputs. Does it make sense to fix
the error messages in VM along with the regression test? If so, here is
the new webrev:
  http://cr.openjdk.java.net/~shade/8023638/webrev.01/

-Aleksey.

From daniel.daugherty at oracle.com  Mon Aug 26 06:35:56 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 26 Aug 2013 07:35:56 -0600
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <521B544E.6090201@oracle.com>
References: <52174654.8020400@oracle.com> <5217C296.7070807@oracle.com>
	<521B544E.6090201@oracle.com>
Message-ID: <521B59BC.9000404@oracle.com>

 > http://cr.openjdk.java.net/~shade/8023638/webrev.01/

hotspot/src/share/vm/runtime/arguments.cpp
     Thanks for fixing the typos.

hotspot/test/runtime/contended/Options.java
     Thanks for updating the test.

Thumbs up.

Dan


On 8/26/13 7:12 AM, Aleksey Shipilev wrote:
> Hi Dan,
>
> On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
>> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>> Here's the webrev:
>>>     http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>> hotspot/test/runtime/contended/Options.java
>>      I count 11 Java process invocations. Will the default timeout
>>      of 120 seconds be enough for a fastdebug '-server -Xcomp'
>>      run on something like Solaris SPARC.
> Linux i5/x86_64 laptop passes this test in 5 seconds. I think there is
> enough headroom for slower machines.
>
>>      The fragments:
>>
>>          "must be the between"
>>          "must be the multiple of 8"
>>
>>      probably match the real error messages, but those messages
>>      aren't quite proper English. I expected:
>>
>>          "must be in between"
>>          "must be a multiple of 8"
> Yes. Unfortunately, this is what VM outputs. Does it make sense to fix
> the error messages in VM along with the regression test? If so, here is
> the new webrev:
>    http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>
> -Aleksey.


From leonid.mesnik at oracle.com  Mon Aug 26 06:38:45 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Mon, 26 Aug 2013 17:38:45 +0400
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <521B544E.6090201@oracle.com>
References: <52174654.8020400@oracle.com> <5217C296.7070807@oracle.com>
	<521B544E.6090201@oracle.com>
Message-ID: <521B5A65.40701@oracle.com>

Dan

ProcessTools.createJavaProcessBuilder don't use test java options. So 
all java invocations are always in '-Xmixed'.

Leonid

On 08/26/2013 05:12 PM, Aleksey Shipilev wrote:
> Hi Dan,
>
> On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
>> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>> Here's the webrev:
>>>     http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>> hotspot/test/runtime/contended/Options.java
>>      I count 11 Java process invocations. Will the default timeout
>>      of 120 seconds be enough for a fastdebug '-server -Xcomp'
>>      run on something like Solaris SPARC.
> Linux i5/x86_64 laptop passes this test in 5 seconds. I think there is
> enough headroom for slower machines.
>
>>      The fragments:
>>
>>          "must be the between"
>>          "must be the multiple of 8"
>>
>>      probably match the real error messages, but those messages
>>      aren't quite proper English. I expected:
>>
>>          "must be in between"
>>          "must be a multiple of 8"
> Yes. Unfortunately, this is what VM outputs. Does it make sense to fix
> the error messages in VM along with the regression test? If so, here is
> the new webrev:
>    http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>
> -Aleksey.


-- 
Leonid Mesnik
JVM SQE


From daniel.daugherty at oracle.com  Mon Aug 26 06:41:31 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 26 Aug 2013 07:41:31 -0600
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <521B5A65.40701@oracle.com>
References: <52174654.8020400@oracle.com> <5217C296.7070807@oracle.com>
	<521B544E.6090201@oracle.com> <521B5A65.40701@oracle.com>
Message-ID: <521B5B0B.30709@oracle.com>

So when we're trying to test with -Xcomp we actually don't?
That sounds rather wrong to me.

Dan


On 8/26/13 7:38 AM, Leonid Mesnik wrote:
> Dan
>
> ProcessTools.createJavaProcessBuilder don't use test java options. So 
> all java invocations are always in '-Xmixed'.
>
> Leonid
>
> On 08/26/2013 05:12 PM, Aleksey Shipilev wrote:
>> Hi Dan,
>>
>> On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
>>> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>>> Here's the webrev:
>>>>     http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>>> hotspot/test/runtime/contended/Options.java
>>>      I count 11 Java process invocations. Will the default timeout
>>>      of 120 seconds be enough for a fastdebug '-server -Xcomp'
>>>      run on something like Solaris SPARC.
>> Linux i5/x86_64 laptop passes this test in 5 seconds. I think there is
>> enough headroom for slower machines.
>>
>>>      The fragments:
>>>
>>>          "must be the between"
>>>          "must be the multiple of 8"
>>>
>>>      probably match the real error messages, but those messages
>>>      aren't quite proper English. I expected:
>>>
>>>          "must be in between"
>>>          "must be a multiple of 8"
>> Yes. Unfortunately, this is what VM outputs. Does it make sense to fix
>> the error messages in VM along with the regression test? If so, here is
>> the new webrev:
>>    http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>>
>> -Aleksey.
>
>


From aleksey.shipilev at oracle.com  Mon Aug 26 06:45:26 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 26 Aug 2013 17:45:26 +0400
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <521B59BC.9000404@oracle.com>
References: <52174654.8020400@oracle.com> <5217C296.7070807@oracle.com>
	<521B544E.6090201@oracle.com> <521B59BC.9000404@oracle.com>
Message-ID: <521B5BF6.8060208@oracle.com>

On 08/26/2013 05:35 PM, Daniel D. Daugherty wrote:
>> http://cr.openjdk.java.net/~shade/8023638/webrev.01/
> 
> hotspot/src/share/vm/runtime/arguments.cpp
>     Thanks for fixing the typos.
> 
> hotspot/test/runtime/contended/Options.java
>     Thanks for updating the test.
> 
> Thumbs up.

Great, thanks!

I need a sponsor to push, here's the changeset:
  http://cr.openjdk.java.net/~shade/8023638/8023638.changeset

-Aleksey.


From mikael.gerdin at oracle.com  Mon Aug 26 06:52:50 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Mon, 26 Aug 2013 13:52:50 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022683: JNI GetStringUTFChars should
	return NULL on allocation failure not abort the VM
Message-ID: <20130826135300.7B13D48B5C@hg.openjdk.java.net>

Changeset: faf2631b9334
Author:    dsimms
Date:      2013-08-26 09:33 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/faf2631b9334

8022683: JNI GetStringUTFChars should return NULL on allocation failure not abort the VM
Summary: Return NULL on OOM from GetStringChars, GetStringUTFChars and Get<PrimitiveType>ArrayElements family of functions.
Reviewed-by: dholmes, coleenp

! src/share/vm/memory/allocation.hpp
! src/share/vm/prims/jni.cpp


From roland.westrelin at oracle.com  Mon Aug 26 07:08:50 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 26 Aug 2013 16:08:50 +0200
Subject: RFR(S): 8016277: Crash in nmethod::is_compiled_by_c1() on x86
In-Reply-To: <F569F6B5-8CBE-44CE-8C8A-C74DF53032DB@oracle.com>
References: <7658B9CF-B363-452D-A0AD-B93F4D574D07@oracle.com>
	<F569F6B5-8CBE-44CE-8C8A-C74DF53032DB@oracle.com>
Message-ID: <5AE25093-1F49-41A4-9F83-DF053EA0DAB4@oracle.com>

> I would appreciate if you could add brackets to the simple if statements:
> if (compiler() == NULL) {
>  return false;
> }
> 
> And also, if you could put the comment above the line instead of to the right:
> 
> // the Method may be reclaimed by class unloading now that the nmethod is in zombie state
> _method = NULL;

I'll make those changes and use set_method() rather than _method = . Thanks for the review.

Roland.

From roland.westrelin at oracle.com  Mon Aug 26 07:09:06 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 26 Aug 2013 16:09:06 +0200
Subject: RFR(S): 8016277: Crash in nmethod::is_compiled_by_c1() on x86
In-Reply-To: <5214D006.1010703@oracle.com>
References: <7658B9CF-B363-452D-A0AD-B93F4D574D07@oracle.com>
	<5214D006.1010703@oracle.com>
Message-ID: <F580D147-576E-4128-89CE-DE9C66CD5B7C@oracle.com>

Thanks for the review, Coleen.

Roland.

From daniel.daugherty at oracle.com  Mon Aug 26 07:13:58 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 26 Aug 2013 08:13:58 -0600
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <521B5BF6.8060208@oracle.com>
References: <52174654.8020400@oracle.com> <5217C296.7070807@oracle.com>
	<521B544E.6090201@oracle.com> <521B59BC.9000404@oracle.com>
	<521B5BF6.8060208@oracle.com>
Message-ID: <521B62A6.4000102@oracle.com>

Aleksey,

I'll sponsor your push shortly.

Dan


On 8/26/13 7:45 AM, Aleksey Shipilev wrote:
> On 08/26/2013 05:35 PM, Daniel D. Daugherty wrote:
>>> http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>> hotspot/src/share/vm/runtime/arguments.cpp
>>      Thanks for fixing the typos.
>>
>> hotspot/test/runtime/contended/Options.java
>>      Thanks for updating the test.
>>
>> Thumbs up.
> Great, thanks!
>
> I need a sponsor to push, here's the changeset:
>    http://cr.openjdk.java.net/~shade/8023638/8023638.changeset
>
> -Aleksey.
>


From karen.kinnear at oracle.com  Mon Aug 26 07:20:10 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 26 Aug 2013 10:20:10 -0400
Subject: Small CDE code review please Re: S RFR: 8012294: remove generic
	default handling
In-Reply-To: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
Message-ID: <9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>

Could I please get a code review for this? I have another fix I need to apply to the same file so I'd like
to get this in please.

This is totally code deletion cleanup.

thanks,
Karen

On Aug 22, 2013, at 9:31 AM, Karen Kinnear wrote:

> Please review:
> 
> webrev:  http://cr.openjdk.java.net/~acorn/8012294/webrev/
> http://bugs.sun.com/view_bug.do?bug_id=8012294
> 
> This is a cleanup bug - fix 8013635 removed generic signature support from the vm
> default method handling, but as a temporary fallback, put this under the develop flag
> ParseGenericDefaults. This has been shaken out sufficiently that the old code under
> that flag can now be removed, including ParseGenericDefaults and ParseAllGenericSignatures,
> both of which were temporary develop flags for early lambda default method handling.
> 
> tests:
> java -XX:+ParseGenericDefaults -XX:+CompileTheWorld -Xbootclasspath/p:<mypath>db.jar - fails before change
> java -XX:+ParseGenericDefaults - won't start VM after change
> java -XX:+ParseAllGenericSignatures - won't start VM after change
> jprt
> defmeth tests (no new failures)
> vm.quick.testlist in progress
> 
> thanks,
> Karen
> 
> 
> 


From kamggg at gmail.com  Mon Aug 26 07:22:14 2013
From: kamggg at gmail.com (Keith McGuigan)
Date: Mon, 26 Aug 2013 10:22:14 -0400
Subject: Small CDE code review please Re: S RFR: 8012294: remove generic
	default handling
In-Reply-To: <9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
Message-ID: <CAFUO74mc_Kk18nYDxC7rfVVdbXC=VQPL8jqrC6mxXteY9XZyhg@mail.gmail.com>

Very sad to see it go, but the deletion looks fine to me.

--
- Keith


On Mon, Aug 26, 2013 at 10:20 AM, Karen Kinnear <karen.kinnear at oracle.com>wrote:

> Could I please get a code review for this? I have another fix I need to
> apply to the same file so I'd like
> to get this in please.
>
> This is totally code deletion cleanup.
>
> thanks,
> Karen
>
> On Aug 22, 2013, at 9:31 AM, Karen Kinnear wrote:
>
> > Please review:
> >
> > webrev:  http://cr.openjdk.java.net/~acorn/8012294/webrev/
> > http://bugs.sun.com/view_bug.do?bug_id=8012294
> >
> > This is a cleanup bug - fix 8013635 removed generic signature support
> from the vm
> > default method handling, but as a temporary fallback, put this under the
> develop flag
> > ParseGenericDefaults. This has been shaken out sufficiently that the old
> code under
> > that flag can now be removed, including ParseGenericDefaults and
> ParseAllGenericSignatures,
> > both of which were temporary develop flags for early lambda default
> method handling.
> >
> > tests:
> > java -XX:+ParseGenericDefaults -XX:+CompileTheWorld
> -Xbootclasspath/p:<mypath>db.jar - fails before change
> > java -XX:+ParseGenericDefaults - won't start VM after change
> > java -XX:+ParseAllGenericSignatures - won't start VM after change
> > jprt
> > defmeth tests (no new failures)
> > vm.quick.testlist in progress
> >
> > thanks,
> > Karen
> >
> >
> >
>
>


-- 
- Keith McGuigan <keith.mcguigan at alumni.unh.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/2a9c4769/attachment.html 

From karen.kinnear at oracle.com  Mon Aug 26 08:05:10 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 26 Aug 2013 11:05:10 -0400
Subject: Small CDE code review please Re: S RFR: 8012294: remove generic
	default handling
In-Reply-To: <CAFUO74mc_Kk18nYDxC7rfVVdbXC=VQPL8jqrC6mxXteY9XZyhg@mail.gmail.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
	<CAFUO74mc_Kk18nYDxC7rfVVdbXC=VQPL8jqrC6mxXteY9XZyhg@mail.gmail.com>
Message-ID: <C2F49B14-DEBE-43DC-8FC9-48B9C48AE9E6@oracle.com>

Thank you Keith for the code review, and thank you for writing the hard
parts of this code. I totally appreciate the code review, and if you have the time,
there are some more coming up :-)

thanks,
Karen

On Aug 26, 2013, at 10:22 AM, Keith McGuigan wrote:

> Very sad to see it go, but the deletion looks fine to me.
> 
> --
> - Keith
> 
> 
> On Mon, Aug 26, 2013 at 10:20 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> Could I please get a code review for this? I have another fix I need to apply to the same file so I'd like
> to get this in please.
> 
> This is totally code deletion cleanup.
> 
> thanks,
> Karen
> 
> On Aug 22, 2013, at 9:31 AM, Karen Kinnear wrote:
> 
> > Please review:
> >
> > webrev:  http://cr.openjdk.java.net/~acorn/8012294/webrev/
> > http://bugs.sun.com/view_bug.do?bug_id=8012294
> >
> > This is a cleanup bug - fix 8013635 removed generic signature support from the vm
> > default method handling, but as a temporary fallback, put this under the develop flag
> > ParseGenericDefaults. This has been shaken out sufficiently that the old code under
> > that flag can now be removed, including ParseGenericDefaults and ParseAllGenericSignatures,
> > both of which were temporary develop flags for early lambda default method handling.
> >
> > tests:
> > java -XX:+ParseGenericDefaults -XX:+CompileTheWorld -Xbootclasspath/p:<mypath>db.jar - fails before change
> > java -XX:+ParseGenericDefaults - won't start VM after change
> > java -XX:+ParseAllGenericSignatures - won't start VM after change
> > jprt
> > defmeth tests (no new failures)
> > vm.quick.testlist in progress
> >
> > thanks,
> > Karen
> >
> >
> >
> 
> 
> 
> 
> -- 
> - Keith McGuigan <keith.mcguigan at alumni.unh.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/9e168093/attachment.html 

From coleen.phillimore at oracle.com  Mon Aug 26 08:13:12 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 26 Aug 2013 11:13:12 -0400
Subject: Small CDE code review please Re: S RFR: 8012294: remove generic
	default handling
In-Reply-To: <C2F49B14-DEBE-43DC-8FC9-48B9C48AE9E6@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
	<CAFUO74mc_Kk18nYDxC7rfVVdbXC=VQPL8jqrC6mxXteY9XZyhg@mail.gmail.com>
	<C2F49B14-DEBE-43DC-8FC9-48B9C48AE9E6@oracle.com>
Message-ID: <521B7088.3080607@oracle.com>


Karen,
This looks good.  Yes, it was good code.
Coleen

On 8/26/2013 11:05 AM, Karen Kinnear wrote:
> Thank you Keith for the code review, and thank you for writing the hard
> parts of this code. I totally appreciate the code review, and if you 
> have the time,
> there are some more coming up :-)
>
> thanks,
> Karen
>
> On Aug 26, 2013, at 10:22 AM, Keith McGuigan wrote:
>
>> Very sad to see it go, but the deletion looks fine to me.
>>
>> --
>> - Keith
>>
>>
>> On Mon, Aug 26, 2013 at 10:20 AM, Karen Kinnear 
>> <karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>> wrote:
>>
>>     Could I please get a code review for this? I have another fix I
>>     need to apply to the same file so I'd like
>>     to get this in please.
>>
>>     This is totally code deletion cleanup.
>>
>>     thanks,
>>     Karen
>>
>>     On Aug 22, 2013, at 9:31 AM, Karen Kinnear wrote:
>>
>>     > Please review:
>>     >
>>     > webrev: http://cr.openjdk.java.net/~acorn/8012294/webrev/
>>     <http://cr.openjdk.java.net/%7Eacorn/8012294/webrev/>
>>     > http://bugs.sun.com/view_bug.do?bug_id=8012294
>>     >
>>     > This is a cleanup bug - fix 8013635 removed generic signature
>>     support from the vm
>>     > default method handling, but as a temporary fallback, put this
>>     under the develop flag
>>     > ParseGenericDefaults. This has been shaken out sufficiently
>>     that the old code under
>>     > that flag can now be removed, including ParseGenericDefaults
>>     and ParseAllGenericSignatures,
>>     > both of which were temporary develop flags for early lambda
>>     default method handling.
>>     >
>>     > tests:
>>     > java -XX:+ParseGenericDefaults -XX:+CompileTheWorld
>>     -Xbootclasspath/p:<mypath>db.jar - fails before change
>>     > java -XX:+ParseGenericDefaults - won't start VM after change
>>     > java -XX:+ParseAllGenericSignatures - won't start VM after change
>>     > jprt
>>     > defmeth tests (no new failures)
>>     > vm.quick.testlist in progress
>>     >
>>     > thanks,
>>     > Karen
>>     >
>>     >
>>     >
>>
>>
>>
>>
>> -- 
>> - Keith McGuigan <keith.mcguigan at alumni.unh.edu 
>> <mailto:keith.mcguigan at alumni.unh.edu>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/1244be5e/attachment-0001.html 

From bharadwaj.yadavalli at oracle.com  Mon Aug 26 08:50:57 2013
From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli)
Date: Mon, 26 Aug 2013 11:50:57 -0400
Subject: Small CDE code review please Re: S RFR: 8012294: remove generic
	default handling
In-Reply-To: <9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
Message-ID: <521B7961.2080505@oracle.com>


The deletions look good to me.

Thanks,

Bharadwaj

On 8/26/2013 10:20 AM, Karen Kinnear wrote:
> Could I please get a code review for this? I have another fix I need to apply to the same file so I'd like
> to get this in please.
>
> This is totally code deletion cleanup.
>
> thanks,
> Karen
>
> On Aug 22, 2013, at 9:31 AM, Karen Kinnear wrote:
>
>> Please review:
>>
>> webrev:  http://cr.openjdk.java.net/~acorn/8012294/webrev/
>> http://bugs.sun.com/view_bug.do?bug_id=8012294
>>
>> This is a cleanup bug - fix 8013635 removed generic signature support from the vm
>> default method handling, but as a temporary fallback, put this under the develop flag
>> ParseGenericDefaults. This has been shaken out sufficiently that the old code under
>> that flag can now be removed, including ParseGenericDefaults and ParseAllGenericSignatures,
>> both of which were temporary develop flags for early lambda default method handling.
>>
>> tests:
>> java -XX:+ParseGenericDefaults -XX:+CompileTheWorld -Xbootclasspath/p:<mypath>db.jar - fails before change
>> java -XX:+ParseGenericDefaults - won't start VM after change
>> java -XX:+ParseAllGenericSignatures - won't start VM after change
>> jprt
>> defmeth tests (no new failures)
>> vm.quick.testlist in progress
>>
>> thanks,
>> Karen
>>
>>
>>


From daniel.daugherty at oracle.com  Mon Aug 26 08:54:24 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 26 Aug 2013 09:54:24 -0600
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <521B62A6.4000102@oracle.com>
References: <52174654.8020400@oracle.com> <5217C296.7070807@oracle.com>
	<521B544E.6090201@oracle.com> <521B59BC.9000404@oracle.com>
	<521B5BF6.8060208@oracle.com> <521B62A6.4000102@oracle.com>
Message-ID: <521B7A30.5010803@oracle.com>

JPRT job: 2013-08-26-152742.ddaugher.8023638_exp

Dan


On 8/26/13 8:13 AM, Daniel D. Daugherty wrote:
> Aleksey,
>
> I'll sponsor your push shortly.
>
> Dan
>
>
> On 8/26/13 7:45 AM, Aleksey Shipilev wrote:
>> On 08/26/2013 05:35 PM, Daniel D. Daugherty wrote:
>>>> http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>>> hotspot/src/share/vm/runtime/arguments.cpp
>>>      Thanks for fixing the typos.
>>>
>>> hotspot/test/runtime/contended/Options.java
>>>      Thanks for updating the test.
>>>
>>> Thumbs up.
>> Great, thanks!
>>
>> I need a sponsor to push, here's the changeset:
>>    http://cr.openjdk.java.net/~shade/8023638/8023638.changeset
>>
>> -Aleksey.
>>
>
>


From karen.kinnear at oracle.com  Mon Aug 26 08:57:03 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 26 Aug 2013 11:57:03 -0400
Subject: Small CDE code review please Re: S RFR: 8012294: remove generic
	default handling
In-Reply-To: <521B7961.2080505@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
	<521B7961.2080505@oracle.com>
Message-ID: <7D182EEB-0E79-4143-A936-87933E9F3543@oracle.com>

Thank you Bharadwaj. I just submitted this, so if I need to resubmit I will add your name.

I'm all set now.

many thanks,
Karen


On Aug 26, 2013, at 11:50 AM, Bharadwaj Yadavalli wrote:

> 
> The deletions look good to me.
> 
> Thanks,
> 
> Bharadwaj
> 
> On 8/26/2013 10:20 AM, Karen Kinnear wrote:
>> Could I please get a code review for this? I have another fix I need to apply to the same file so I'd like
>> to get this in please.
>> 
>> This is totally code deletion cleanup.
>> 
>> thanks,
>> Karen
>> 
>> On Aug 22, 2013, at 9:31 AM, Karen Kinnear wrote:
>> 
>>> Please review:
>>> 
>>> webrev:  http://cr.openjdk.java.net/~acorn/8012294/webrev/
>>> http://bugs.sun.com/view_bug.do?bug_id=8012294
>>> 
>>> This is a cleanup bug - fix 8013635 removed generic signature support from the vm
>>> default method handling, but as a temporary fallback, put this under the develop flag
>>> ParseGenericDefaults. This has been shaken out sufficiently that the old code under
>>> that flag can now be removed, including ParseGenericDefaults and ParseAllGenericSignatures,
>>> both of which were temporary develop flags for early lambda default method handling.
>>> 
>>> tests:
>>> java -XX:+ParseGenericDefaults -XX:+CompileTheWorld -Xbootclasspath/p:<mypath>db.jar - fails before change
>>> java -XX:+ParseGenericDefaults - won't start VM after change
>>> java -XX:+ParseAllGenericSignatures - won't start VM after change
>>> jprt
>>> defmeth tests (no new failures)
>>> vm.quick.testlist in progress
>>> 
>>> thanks,
>>> Karen
>>> 
>>> 
>>> 
> 


From ron.durbin at oracle.com  Mon Aug 26 08:57:03 2013
From: ron.durbin at oracle.com (Ron Durbin)
Date: Mon, 26 Aug 2013 08:57:03 -0700 (PDT)
Subject: Small CDE code review please Re: S RFR: 8012294: remove generic
	default handling
In-Reply-To: <9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
Message-ID: <18edabfa-6bb4-4f41-9695-204d9d18446e@default>

Karen

This looks good. I like to see code removed. :)
My review is unofficial.

Ron Durbin  

> -----Original Message-----
> From: Karen Kinnear
> Sent: Monday, August 26, 2013 8:20 AM
> To: Karen Kinnear
> Cc: Hotspot dev runtime
> Subject: Small CDE code review please Re: S RFR: 8012294: remove generic default handling
> 
> Could I please get a code review for this? I have another fix I need to apply to the same
> file so I'd like to get this in please.
> 
> This is totally code deletion cleanup.
> 
> thanks,
> Karen
> 
> On Aug 22, 2013, at 9:31 AM, Karen Kinnear wrote:
> 
> > Please review:
> >
> > webrev:  http://cr.openjdk.java.net/~acorn/8012294/webrev/
> > http://bugs.sun.com/view_bug.do?bug_id=8012294
> >
> > This is a cleanup bug - fix 8013635 removed generic signature support
> > from the vm default method handling, but as a temporary fallback, put
> > this under the develop flag ParseGenericDefaults. This has been shaken
> > out sufficiently that the old code under that flag can now be removed,
> > including ParseGenericDefaults and ParseAllGenericSignatures, both of which were temporary
> develop flags for early lambda default method handling.
> >
> > tests:
> > java -XX:+ParseGenericDefaults -XX:+CompileTheWorld
> > -Xbootclasspath/p:<mypath>db.jar - fails before change java
> > -XX:+ParseGenericDefaults - won't start VM after change java
> > -XX:+ParseAllGenericSignatures - won't start VM after change jprt
> > defmeth tests (no new failures) vm.quick.testlist in progress
> >
> > thanks,
> > Karen
> >
> >
> >
> 

From karen.kinnear at oracle.com  Mon Aug 26 09:05:01 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 26 Aug 2013 12:05:01 -0400
Subject: Small CDE code review please Re: S RFR: 8012294: remove generic
	default handling
In-Reply-To: <18edabfa-6bb4-4f41-9695-204d9d18446e@default>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
	<18edabfa-6bb4-4f41-9695-204d9d18446e@default>
Message-ID: <597251EA-8744-42DA-B4EE-F77F4F003571@oracle.com>

Thanks for the review Ron.

I'm all set folks - thanks for the quick responses!
Karen

On Aug 26, 2013, at 11:57 AM, Ron Durbin wrote:

> Karen
> 
> This looks good. I like to see code removed. :)
> My review is unofficial.
> 
> Ron Durbin  
> 
>> -----Original Message-----
>> From: Karen Kinnear
>> Sent: Monday, August 26, 2013 8:20 AM
>> To: Karen Kinnear
>> Cc: Hotspot dev runtime
>> Subject: Small CDE code review please Re: S RFR: 8012294: remove generic default handling
>> 
>> Could I please get a code review for this? I have another fix I need to apply to the same
>> file so I'd like to get this in please.
>> 
>> This is totally code deletion cleanup.
>> 
>> thanks,
>> Karen
>> 
>> On Aug 22, 2013, at 9:31 AM, Karen Kinnear wrote:
>> 
>>> Please review:
>>> 
>>> webrev:  http://cr.openjdk.java.net/~acorn/8012294/webrev/
>>> http://bugs.sun.com/view_bug.do?bug_id=8012294
>>> 
>>> This is a cleanup bug - fix 8013635 removed generic signature support
>>> from the vm default method handling, but as a temporary fallback, put
>>> this under the develop flag ParseGenericDefaults. This has been shaken
>>> out sufficiently that the old code under that flag can now be removed,
>>> including ParseGenericDefaults and ParseAllGenericSignatures, both of which were temporary
>> develop flags for early lambda default method handling.
>>> 
>>> tests:
>>> java -XX:+ParseGenericDefaults -XX:+CompileTheWorld
>>> -Xbootclasspath/p:<mypath>db.jar - fails before change java
>>> -XX:+ParseGenericDefaults - won't start VM after change java
>>> -XX:+ParseAllGenericSignatures - won't start VM after change jprt
>>> defmeth tests (no new failures) vm.quick.testlist in progress
>>> 
>>> thanks,
>>> Karen
>>> 
>>> 
>>> 
>> 


From jiangli.zhou at oracle.com  Mon Aug 26 09:59:50 2013
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Mon, 26 Aug 2013 09:59:50 -0700
Subject: Request for review:8023477: Invalid CP index when reading
	ConstantPool
In-Reply-To: <D370EE38-9400-4C14-A32F-B1F5E62FA7EF@oracle.com>
References: <51F978B6.3050209@oracle.com> <52055DAF.90707@oracle.com>
	<520924D1.3040800@oracle.com> <52094970.1030206@oracle.com>
	<4572EF82-2398-4E3F-9626-3253F735969E@oracle.com>
	<52164A1B.308@oracle.com> <521653D7.9000404@oracle.com>
	<5216660A.7080801@oracle.com> <521668CE.7010500@oracle.com>
	<52168027.7040903@oracle.com> <52168186.6030100@oracle.com>
	<521687A0.1010607@oracle.com> <52168C3E.50200@oracle.com>
	<52168D9E.8010509@oracle.com> <521691F6.9080303@oracle.com>
	<52169BDF.1090800@oracle.com>
	<4BE46744-56C9-4688-A10C-B85DECB6DE0D@oracle.com>
	<52177DE5.9040701@oracle.com> <5217A327.2080506@oracle.com>
	<5217D8FE.9090507@oracle.com>
	<D370EE38-9400-4C14-A32F-B1F5E62FA7EF@oracle.com>
Message-ID: <521B8986.2030608@oracle.com>

Thanks, Staffan!

Jiangli

On 08/26/2013 01:13 AM, Staffan Larsen wrote:
> Looks good.
>
> Thanks,
> /Staffan
>
> On 23 aug 2013, at 23:49, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>
>> Hi,
>>
>> Please review the fix for 8023477:
>>
>>   http://cr.openjdk.java.net/~jiangli/8023477/webrev.00/
>>
>> Both tests reported by the bug failed due to the same problem. They both are passing now.
>>
>> The original memory reduction change for 8021948 turned out to be a little trickier than I expected.
>>
>> Thanks,
>> Jiangli
>>
>>
>> On 08/23/2013 11:00 AM, Jiangli Zhou wrote:
>>> I found the issue in the SA code. For class without generic signature, the InstanceKlass::_generic_signature_index is 0. Need to check for this case in the SA code. I'm working on the fix and doing testing.
>>>
>>> Thanks,
>>> Jiangli
>>>
>>> On 08/23/2013 08:21 AM, Jiangli Zhou wrote:
>>>> Hi Staffan,
>>>>
>>>> Thanks for the info. Will look into that one.
>>>>
>>>> Jiangli
>>>>
>>>> On 08/23/2013 05:27 AM, Staffan Larsen wrote:
>>>>> Unfortunately there are two more tests that started failing after the initial change. See: JDK-8023477.
>>>>>
>>>>> /Staffan
>>>>>
>>>>> On 23 aug 2013, at 01:16, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>>>>>
>>>>>> Hi Coleen,
>>>>>>
>>>>>> Yes, that's the case. Thanks for the review. I'll push this to hotspot-rt.
>>>>>>
>>>>>> Thanks,
>>>>>> Jiangli
>>>>>>
>>>>>> On 08/22/2013 03:34 PM, Coleen Phillimore wrote:
>>>>>>> Hi,
>>>>>>> Is it the case that the old index isn't in the index map because it didn't change?  If so, this looks correct.
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>>
>>>>>>> On 08/22/2013 06:15 PM, Jiangli Zhou wrote:
>>>>>>>> On 08/22/2013 03:10 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>> Hi Jiangli,
>>>>>>>>>
>>>>>>>>> The fix is good and safe.
>>>>>>>>> I'm happy you fixed another case as well!
>>>>>>>>> Let's consider current bug as a clean-up issue so that we do not need to file a separate bug. :)
>>>>>>>> Ok.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jiangli
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Serguei
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/22/13 2:50 PM, Jiangli Zhou wrote:
>>>>>>>>>> Hi Serguei,
>>>>>>>>>>
>>>>>>>>>> I've also made change to the case that you discovered. Please let me know if you think a separate bug should be filed to track it instead.
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Jiangli
>>>>>>>>>>
>>>>>>>>>> On 08/22/2013 02:24 PM, Jiangli Zhou wrote:
>>>>>>>>>>> Hi Serguei,
>>>>>>>>>>>
>>>>>>>>>>> Thank you very much for the review and confirmation with the test.
>>>>>>>>>>>
>>>>>>>>>>> Jiangli
>>>>>>>>>>>
>>>>>>>>>>> On 08/22/2013 02:18 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>>> Hi Jiangli,
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you for the quick fix which looks fine to me.
>>>>>>>>>>>> I confirm the test is passed with it.
>>>>>>>>>>>>
>>>>>>>>>>>> Staffan, thank you for the regression isolation.
>>>>>>>>>>>> I've noticed the following fragment in this file which seems has a similar issue:
>>>>>>>>>>>>
>>>>>>>>>>>>   // We also need to rewrite the parameter name indexes, if there is
>>>>>>>>>>>>   // method parameter data present
>>>>>>>>>>>>   if(method->has_method_parameters()) {
>>>>>>>>>>>>     const int len = method->method_parameters_length();
>>>>>>>>>>>>     MethodParametersElement* elem = method->method_parameters_start();
>>>>>>>>>>>>
>>>>>>>>>>>>     for (int i = 0; i < len; i++) {
>>>>>>>>>>>>       const u2 cp_index = elem[i].name_cp_index;
>>>>>>>>>>>>       elem[i].name_cp_index = find_new_index(cp_index);
>>>>>>>>>>>>     }
>>>>>>>>>>>>   }
>>>>>>>>>>>> } // end rewrite_cp_refs_in_method()
>>>>>>>>>>>>
>>>>>>>>>>>> The result of the find_new_index() above is not checked for 0.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Serguei
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/22/13 12:38 PM, Jiangli Zhou wrote:
>>>>>>>>>>>>> Hi Staffan, Serguei and others,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is the webrev for the 8023547 fix:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~jiangli/8023547/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jiangli


From yumin.qi at oracle.com  Mon Aug 26 10:01:40 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 26 Aug 2013 10:01:40 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521B4041.5050300@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
Message-ID: <521B89F4.6010403@oracle.com>

Bengt,

   Thanks for your comments.
   Yes, as you said, the purpose of rotating logs is primarily targeted 
for saving disk space. This bug is supplying  customers another option 
to prevent the previous gc logs from removed by restart app without 
making copy. Now with this pid and time stamp included in file name,  we 
have more options for users. It is up to user to make decision to or not 
to keep the logs. We cannot handle all the requests in JVM, but we can 
offer the choices for users I think. Any way, with either the previous 
rotating version, or the one I am working, the logs will not grow 
constantly without limit to blow storage out as long as users give 
enough attention.

   My concern is for no log rotation, should we still use time stamp in 
file name? I have one version for this, I hope get more comments for that.

   More comments are appreciated by sending to more wide audience, 
especially sustaining, they have more experience with customer request.

Thanks
Yumin



On 8/26/2013 4:47 AM, Bengt Rutisson wrote:
>
> Hi Yumin and Tao,
>
> I have not reviewed the code change but I have a comment inlined below.
>
> On 8/24/13 1:05 AM, Yumin Qi wrote:
>> Tao,
>>
>>   Thanks for your review.
>>
>> On 8/23/2013 3:33 PM, Tao Mao wrote:
>>> Hi,
>>>
>>> I reviewed most of the code and test-ran a build from it. It's a 
>>> very cool and important improvement.
>>>
>>> Thank you for putting together these on our wishlist for long.
>>>
>>> Below are some comments.
>>>
>>> 1. src/share/vm/runtime/arguments.cpp
>>>
>>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>>
>>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>>
>>> I worked on a problem of enabling gc log limit over 2G 
>>> (JDK-7122222). So it seems that customers sometimes want gc logs to 
>>> be very large.
>>>
>> Sure, will add.
>>> 2. src/share/vm/runtime/arguments.hpp
>>>
>>> (1) with the current changeset, we only append date&time to 
>>> file_name w/ +UseGCLogFileRotation; if not, we won't have date&time 
>>> info.
>>>
>>> I think it would be useful to let both cases (w/ and w/o 
>>> UseGCLogFileRotation) have date&time in order to solve the 
>>> overwritten problem (e.g. JDK-8020667). In fact, having that, we 
>>> actually solve JDK-8020667.
>>>
>>> If you want to have that, basically you need to work on the 
>>> FileStream constructor methods fileStream().
>>>
>> I can change that, if no objection from others. This also will 
>> simplify the setting of file name here.
>
> I think appending a timestamp to the log file name is a nice idea, but 
> I think it is also a bit scary. There are users who restart their 
> applications regularly. With the suggested idea such users will now 
> risk filling up their disk space with log files. I imagine that that 
> will not be appreciated by everyone. Such a change should probably be 
> discussed more thoroughly than just in a review request.
>
> Thanks,
> Bengt
>
>
>>
>>> (2) Would it be better to rename method name reformat_filename() to 
>>> extend_filename()?
>>>
>>> (3) Typos and suggestion
>>> 537 // rotate file in names filename.0, filename.1, ..., 
>>> filename.<NumberOfGCLogFiles - 1>
>>> *=> extended_filename.0*
>>>
>>> 538 // filename contains pid and time when the fist file created. 
>>> The current filename is
>>> *=> *the*first *file created.
>>>
>>> 539 // gc_log_file_name + pid<pid> + 
>>> YYYY-MM-DD_HH-MM-SS.<i>.current, where i is current
>>> 540 // rotation file number. After it reaches max file size, the 
>>> file will be saved and
>>> 541 // renamed with .current removed from its tail.
>>>
>> Will change that.
>>> 3. For your point 5), I don't quite get it. In my test-run, I tried 
>>> to change file permission to unreadable and unwritable, but VM would 
>>> later change the permission back anyway.
>>>
>>> So could you bring up some use cases of that functionality to give 
>>> more details?
>>>
>> Changing file permission will not stop the file create, in this 
>> rotation, the file opened/saved/removed/renamed -> then repeat. What 
>> I have done is change the while directory to read only, then the 
>> create failed so rotation stopped.
>>
>>> 4. Will you write jtreg tests for this functionality? It looks 
>>> possible to write some tests, at least checking the format of log 
>>> names.
>>>
>> Good suggestion, I will add one.
>>
>>> Thanks.
>>> Tao
>>>
>>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>>> Could I get  a GC staff review the change? Need more reviewers to 
>>>> push this in.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>>> Hi, all
>>>>>
>>>>>   This is second version after feedback from first round.
>>>>>   The changes are:
>>>>>
>>>>>   1) file name will be based on gc log file name 
>>>>> (-Xloggc:filename), pid (process id) and time when the first 
>>>>> rotation file created:
>>>>>        <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>>   2) If rotate in same file, file name is as in 1), if rotate in 
>>>>> multiple files, .<i> will append to above file name.
>>>>>   3) every time file rotated, file name and time when file created 
>>>>> will be logged to head/tail, this is same as first version.
>>>>>   4) current file has name 
>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>>        This is similar to first version.
>>>>>        By adapting such name format we will never loss logs in 
>>>>> case apps stops and restart, the log files will not be overwritten 
>>>>> since time stamp in file names.
>>>>>    5) If open file failed, turn off gc log rotation.
>>>>>         If due to some reason, file operation failed (such as 
>>>>> permission changed etc), with log file opened, logging still 
>>>>> works, but at
>>>>>         saving and renaming, the file operation will fail, this 
>>>>> will lead not all files saved.
>>>>>
>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>>
>>>>>      Tested with jtreg, JPRT.
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>>> Hi,
>>>>>>
>>>>>>   Can I have your review for this small changes?
>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>>>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>>
>>>>>>    This is for a enhancement to add head/tail message to the 
>>>>>> logging files to assist reading GC output.
>>>>>>    1. modified prompt message if invalid arguments used for log 
>>>>>> rotating;
>>>>>>    2. add time and file name message to log file head/tail.
>>>>>>    3. for easily identify which log file is current, use file 
>>>>>> name like <filename>.n.current, after it reaches maximum size, 
>>>>>> rename it to <filename>.n
>>>>>>         On Windows, there is no F_OK (existing test) definition, 
>>>>>> F_OK is defined as "0" and for _access of VC++, it just describes:
>>>>>>
>>>>>> modevalue
>>>>>>
>>>>>>
>>>>>>
>>>>>> Checks file for
>>>>>>
>>>>>> 00
>>>>>>
>>>>>>
>>>>>>
>>>>>> Existence only
>>>>>>
>>>>>> 02
>>>>>>
>>>>>>
>>>>>>
>>>>>> Write-only
>>>>>>
>>>>>> 04
>>>>>>
>>>>>>
>>>>>>
>>>>>> Read-only
>>>>>>
>>>>>> 06
>>>>>>
>>>>>>
>>>>>>
>>>>>> Read and write
>>>>>>
>>>>>>
>>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>>> The definition are consistent with unistd.h.
>>>>>>
>>>>>>     Test: JPRT and jtreg.
>>>>>>
>>>>>>    Thanks
>>>>>>    Yumin
>>>>>
>>>>
>>
>>
>


From harold.seigel at oracle.com  Mon Aug 26 10:16:26 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Mon, 26 Aug 2013 13:16:26 -0400
Subject: RFR 8022183: GCC 4.6 changes default setting for
	omit-frame-pointer which breaks hotspot stack walking
In-Reply-To: <5216C649.2000208@oracle.com>
References: <52152EE3.2040804@oracle.com> <52153ECD.9030006@oracle.com>
	<52161B70.3090907@oracle.com> <52162229.6070803@oracle.com>
	<5216277A.7090205@oracle.com> <5216C649.2000208@oracle.com>
Message-ID: <521B8D6A.9090002@oracle.com>

Thanks David.

I fixed the typo before I checked it in.

Harold

On 8/22/2013 10:17 PM, David Holmes wrote:
> On 23/08/2013 1:00 AM, harold seigel wrote:
>> Please review this updated webrev for bug 8022183:
>> http://cr.openjdk.java.net/~hseigel/bug_8022183.2/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183.2/>
>>
>> This change updates the comment and moves the "-fno-omit-frame-pointer"
>> option to gcc.make.  This change was tested on both 32 and 64 bit Linux
>> builds using NMT and GCBasher. Also, the build log was inspected to make
>> sure that "-fno-omit-frame-pointer" was specified during the C++ 
>> compiles.
>>
>> I verified that Clang also accepts the "-fno-omit-frame-pointer" option.
>
> Thanks for doing all that.
>
> One minor typo in the comment: Explicity
>
> David
>
>> Thanks, Harold
>>
>>
>> On 8/22/2013 10:37 AM, harold seigel wrote:
>>> Yes, I'll update the comment.
>>>
>>> Thanks, Harold
>>>
>>> On 8/22/2013 10:08 AM, Coleen Phillimore wrote:
>>>>
>>>> Harold,
>>>>
>>>> Regarding the comment, isn't it not just the serviceability agent but
>>>> the stack trace in hs_err and the stack walking in NMT. Isn't it
>>>> generally "Stack walking in the JVM relies on frame pointer..."
>>>>
>>>> thanks,
>>>> Coleen
>>>>
>>>> On 08/21/2013 06:27 PM, Daniel D. Daugherty wrote:
>>>>> On 8/21/13 3:19 PM, harold seigel wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this small fix for bug 8022183.  This fix is needed
>>>>>> in order to build hotspot on 32-bit Linux with newer versions of
>>>>>> gcc. The fix explicitly specifies "-fno-omit-frame-pointer" in the
>>>>>> makefile for 32-bit Linux.
>>>>>>
>>>>>> The fix was tested using NMT with -version and with GCBasher.
>>>>>>
>>>>>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8022183/
>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8022183/>
>>>>>
>>>>> make/linux/makefiles/i486.make
>>>>>     No comments.
>>>>>
>>>>> Thumbs up!
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>>
>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022183
>>>>>>
>>>>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022183
>>>>>>
>>>>>> Thanks, Harold
>>>>>
>>>>
>>>
>>


From karen.kinnear at oracle.com  Mon Aug 26 10:22:04 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 26 Aug 2013 13:22:04 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <E97C13DD-AC22-45B1-9CC1-1FD4A044B95C@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
	<94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
	<F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>
	<52119939.50205@oracle.com>
	<2415DA74-C2C1-4B34-8598-9A0072FA7BA9@oracle.com>
	<925B8B0B-E7A9-4934-B8F8-FAABB6492B01@oracle.com>
	<727C0BA7-6E86-4FBB-A1CB-8E7670A27214@oracle.com>
	<E97C13DD-AC22-45B1-9CC1-1FD4A044B95C@oracle.com>
Message-ID: <E4F45E47-2571-46B6-BF33-4AA554286089@oracle.com>

David,

In general, I really like the cleanup - I like the CallInfo usage and the relying on the
linkResolver logic in a single location. These are all requests for improved comments,
except for the last one, which is of course a personal preference, so ok to check in without
changing.

couple of questions:
1. In init_method_MemberNames
The comment "interfaces are interconvertible" is no longer true with abstract methods.
The next sentence I believe is true, so perhaps you could delete the first one

2. In method.cpp in is_final_method
Could you please delete the comment lies 513-514
"Should return true for private methods also, since there is no way to override them?"

Yes, you do not override private methods. However, this call is used to determine if you
need a vtable entry. Private methods always get a vtable entry to handle backward compatibility
with classes - i.e. you can have the same name of a private method local to your class and also
inherit a method of from your superclass, which will get inherited around the private method, by
your child.

And yes, you can have an overpass method, which does not require a vtable entry,
so the "can this happen?" answer is yes - so you can remove the question.

4. klassVtable.cpp
lines 773-774
I'd like to understand better what this case represents?
Same question interpreterRuntime.cpp
CharSequence.toString - use vtable not itable (706-707)

5. linkResolver.hpp
  direct_call line 45, and _call_kind line 55: 
     I think this includes both static and invokeSpecial calls - correct? so the "static" in the comment
   in 55 might want to be expanded

6. linkResolver.cpp
CallInfo::CallInfo:
  Why are _selected_klass and _selected_method set to resolved_klass and resolve_method?
  I thought the CallInfo contains the static linktime resolution information (resolved_method, resolved_klass
  which are passed in) and then also the receiver - but that the selected_klass and selected_method
  would be calculated later?

  - or are these set for when there is no receiver but replaced if there is one, i.e. a non-null placeholder?
   Isn't this more confusing than leaving as null and for instance in runtime_resolve_interface_method,
   not checking for sel_method.is_null() if !check_null_and_abstract?

thanks,
Karen


On Aug 22, 2013, at 5:04 PM, David Chase wrote:

> After further study, we think the different-wrong-answers are a symptom of a different bug
> (to be filed) where Methodhandle processing does the wrong thing (fails to null-check or
> do appropriate handshakes) when presented with empty (null) method from a virtual or
> interface invocation.
> 
> So, if I may have another Reviewer (I think one more is needed for something this large)?
> 
> On 2013-08-19, at 6:46 PM, David Chase <david.r.chase at oracle.com> wrote:
> 
>> Karen Kinnear would like me to study, carefully, the wrong answer that occur in one of the default methods tests.
>> Apparently this is an instance of a test where the wrong answers are still interesting -- this patch fails less, but
>> in a few cases it fails differently.
>> 
>> David
>> 
>> On 2013-08-19, at 6:15 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> Looks good.  -- Chris
>>> 
>>> On Aug 19, 2013, at 11:13 AM, David Chase <david.r.chase at oracle.com> wrote:
>>> 
>>>> New version, with Christian's and John's fixes (and limited use of err_msg_res):
>>>> 
>>>> http://cr.openjdk.java.net/~drchase/8014013/webrev.03/
>>>> 
>>>> retested (jtreg) on Mac against hotspot/test/compiler, jdk/test/{jdk,java/util}
>>>> 
>>>> David
>>>> 
>>>> 
>>>> On 2013-08-19, at 12:04 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>> 
>>>>> On 19/08/2013 8:24 AM, David Chase wrote:
>>>>>> A question about err_msg_res -- should that generally be used in place of err_msg,
>>>>>> or only in certain source directories, and if so, which ones?
>>>>> 
>>>>> I can't answer that but be aware that there is an issue with using err_msg_res as it is unclear as to whom has responsibility for ensuring there is a ResourceMark on the stack. There's an open bug on that - 8022187.
>>>>> 
>>>>> David
>>>>> 
>>>>>> On 2013-08-17, at 1:41 AM, John Rose <john.r.rose at oracle.com> wrote:
>>>>>> 
>>>>>>> On Aug 16, 2013, at 1:05 PM, David Chase <david.r.chase at oracle.com> wrote:
>>>>>>> 
>>>>>>>> How does this look?
>>>>>>>> 
>>>>>>>> void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
>>>>>>>> if (_cp.is_null() || field_holder() != ik) {
>>>>>>>> _cp = constantPoolHandle(Thread::current(), ik->constants());
>>>>>>>> // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
>>>>>>>> assert(field_holder() == ik, "must be already initialized to this class");
>>>>>>> 
>>>>>>> Good.
>>>>>>> 
>>>>>>> As a side note, this bit of code (and many others) assume that there is a 1-1 correspondence between constant pools and instance klasses.
>>>>>>> 
>>>>>>> I hope we can change this some day; the tracking bug is http://bugs.sun.com/view_bug.do?bug_id=6711913
>>>>>>> 
>>>>>>> ? John
>>>>>> 
>>>> 
>>> 
>> 
> 


From coleen.phillimore at oracle.com  Mon Aug 26 10:55:42 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 26 Aug 2013 13:55:42 -0400
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <5217C4A8.8000000@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
	<5216FBA9.50807@oracle.com> <5217072C.5020106@oracle.com>
	<5217A19F.7020103@oracle.com> <5217ADDD.9090604@oracle.com>
	<5217C4A8.8000000@oracle.com>
Message-ID: <521B969E.9020609@oracle.com>


Calvin,

The code change looks great.  Thank you for doing the cleanups also.

Coleen

On 8/23/2013 4:23 PM, Calvin Cheung wrote:
> Hi Misha,
>
> Thanks for reviewing the test case.
>
> All,
>
> I've updated the webrev with the one-line change in classLoader.cpp.
> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>
> thanks,
> Calvin
>
> On 8/23/2013 11:45 AM, Mikhailo Seledtsov wrote:
>> Hi Calvin,
>>
>>  I only reviewed the test portion. It looks good to me.
>>
>> Misha
>>
>> On 8/23/2013 1:53 PM, Calvin Cheung wrote:
>>> On 8/22/2013 11:54 PM, David Holmes wrote:
>>>> On 23/08/2013 4:05 PM, Calvin Cheung wrote:
>>>>> On 8/22/2013 5:21 PM, David Holmes wrote:
>>>>>> Hi Calvin,
>>>>>>
>>>>>> I'm having trouble keeping track of this one ...
>>>>>>
>>>>>> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>>>>>>> Note that the synopsis of the bug has been changed from:
>>>>>>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0
>>>>>>> Build 4"
>>>>>>>
>>>>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>>>>>>
>>>>>>> I've included the suggestions from Coleen and Ioi in this 
>>>>>>> version of
>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>>
>>>>>> I don't understand your _has_error logic:
>>>>>>
>>>>>>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>>>>  326   if (cpe == NULL) {
>>>>>>  327     _has_error = true;
>>>>>>  328     return NULL;
>>>>>>
>>>>>> we will only hit line 327 if resolve_entry returns NULL _without_
>>>>>> there being an exception pending. How does that occur? What is
>>>>>> different about the two cases regardless?
>>>>> The _has_error flag was suggested by Ioi and is to avoid opening the
>>>>> invalid jar file again.
>>>>
>>>> Can't we just remove it from the classpath representation?
>>> I think it can be done if the error happens during vm initialization.
>>> But for this test scenario, the error happens after vm init.
>>> Perhaps this should be addressed as a separate bug fix?
>>>>
>>>>> The call sequence is as follows:
>>>>> ClassLoader::load_classfile()
>>>>>      -> LazyClassPathEntry::open_stream()
>>>>>          -> LazyClassPathEntry::resolve_entry()
>>>>>              -> ClassLoader::create_class_path_entry()
>>>>>
>>>>> For second time, it'll return NULL without calling resolve_entry() 
>>>>> again.
>>>>>
>>>>> The LazyClassPathEntry instance is instantiated by the following 
>>>>> calls:
>>>>> ClassLoader::setup_bootstrap_search_path()
>>>>>      ->ClassLoader::update_class_path_entry_list()
>>>>>          ->ClassLoader::create_class_path_entry(path, &st,
>>>>> LazyBootClassLoader, CHECK)
>>>>>
>>>>> LazyBootClassLoader is set to true by default.
>>>>
>>>> Sorry but I don't see how that answers my question. Based on the 
>>>> below there isn't a second time because the first time will cause 
>>>> the pending exception which will terminate the VM. Even if we dont 
>>>> terminate and somehow call this again, we didn't set _has_error the 
>>>> first time anyway! ???
>>> Let's not confused with the classes we're preloading during vm 
>>> initialization and the applications classes after vm initialization.
>>>
>>> Consider the following test case:
>>> public class test3 {
>>>     public static void main(String[] args) {
>>>         try {
>>>             //Class cls = Class.forName("javax.crypto.KeyGenerator");
>>>             //System.out.println("Class = " + cls.getName());
>>>             Class cls = Class.forName("xxx");
>>>             System.out.println("Class = " + cls.getName());
>>>         } catch (ClassNotFoundException cnfe) {
>>>             cnfe.printStackTrace();
>>>         }
>>>         try {
>>>             Class cls2 = Class.forName("yyy");
>>>             System.out.println("Class = " + cls2.getName());
>>>         } catch (ClassNotFoundException cnfe) {
>>>             cnfe.printStackTrace();
>>>         }
>>>     }
>>> }
>>>
>>> Let's say we have a dummy.jar with 0-byte and test3.class in the 
>>> same directory.
>>> And command line as follows:
>>> java -Xbootclasspath/a:dummy.jar -cp . test3
>>>
>>> During vm init. (as in the above 
>>> ClassLoader::setup_bootstrap_search_path() call sequence), there's 
>>> no problem because vm doesn't need to read dummy.jar as all other 
>>> preload classes can be found in jdk's jar files (rt.jar, jce.jar, 
>>> etc.) (Note: this isn't the case with 7u25, we were trying to 
>>> preload a non-existing class, please refer to my comment in the bug 
>>> report.)
>>>
>>> When vm tries to load the class for the test case (test3.class), 
>>> it'll call into LazyClassPathEntry::open_stream(). This is the first 
>>> time resolve_entry() returns NULL and the _has_error flag will be 
>>> set to true. The next time vm will try to load xxx.class. Since 
>>> _has_error was set to NULL, it will return NULL without calling 
>>> resolve_entry(). Same story for the third time for the yyy.class.
>>>
>>> call stack as follows:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, const 
>>> stat * st, bool lazy, Thread * __the_thread__) Line 515    C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry(Thread * 
>>> __the_thread__)  Line 304 + 0x19 bytes    C++
>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name, 
>>> Thread * __the_thread__)  Line 325 + 0xc bytes    C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 909 + 0x1b bytes    C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1301 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 237 + 0x23 bytes    C++
>>> >    jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>>> name)  Line 770 + 0x12 bytes    C++
>>>      java.dll!70671e8c()
>>>
>>> I've just noticed that there's a slight error in my change in line 
>>> #325 of classLoader.cpp:
>>>
>>> ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>
>>> should be
>>>
>>> ClassPathEntry* cpe = resolve_entry(THREAD);
>>>
>>> Otherwise, it'll skip the rest of the statements.
>>> I'll update webrev shortly.
>>>
>>>>
>>>>>>
>>>>>> And we still have this sequence:
>>>>>>
>>>>>> void ClassLoader::initialize() {
>>>>>>   assert(_package_hash_table == NULL, "should have been 
>>>>>> initialized by
>>>>>> now.");
>>>>>>   EXCEPTION_MARK;
>>>>>>   ...
>>>>>>   setup_bootstrap_search_path();
>>>>>>     -> update_class_path_entry_list(path, false);
>>>>>>       ->  create_class_path_entry((char *)path, st, &new_entry,
>>>>>> LazyBootClassLoader, CHECK);
>>>>> As mentioned above, this call sequence is for instantiating the
>>>>> LazyClassPathEntry instances.
>>>>>>
>>>>>> So if we return after the call to create_class_path_entry with an
>>>>>> exception pending we will crash when we hit the EXCEPTION_MARK. Why
>>>>>> doesn't this happen?
>>>>> During vm initilization, it's ok to have exception pending. The
>>>>> destructor of ExceptionMark is as follows:
>>>>> ExceptionMark::~ExceptionMark() {
>>>>>    if (_thread->has_pending_exception()) {
>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>> recursion
>>>>>      if (is_init_completed()) {
>>>>>        exception->print();
>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>> exceptions");
>>>>>      } else {
>>>>>        vm_exit_during_initialization(exception);
>>>>>      }
>>>>>    }
>>>>> }
>>>>>
>>>>> So if is_init_completed() is false, it'll just print an error and 
>>>>> exit.
>>>>
>>>> So we do hit it - ok. So this yet another place where the VM should 
>>>> not abort during initialization.
>>> Yes and this is for preloading class scenario during vm init.
>>> IMHO, I don't think we should change the behavior now.
>>>
>>> thanks,
>>> Calvin
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Tests:
>>>>>>>      jprt
>>>>>>>          (in progress - only about 30 tests left on the windows
>>>>>>> platforms, no failure so far;
>>>>>>>           a previous run with only Coleen's suggestions was 
>>>>>>> successful)
>>>>>>>
>>>>>>>      vm.quick.testlist on linux_x64
>>>>>>>
>>>>>>> Please review.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Calvin
>>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/7bd5e1f3/attachment-0001.html 

From ioi.lam at oracle.com  Mon Aug 26 11:09:15 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 26 Aug 2013 11:09:15 -0700
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <5217C4A8.8000000@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
	<5216FBA9.50807@oracle.com> <5217072C.5020106@oracle.com>
	<5217A19F.7020103@oracle.com> <5217ADDD.9090604@oracle.com>
	<5217C4A8.8000000@oracle.com>
Message-ID: <521B99CB.6050202@oracle.com>

Calvin,

Looks good.

Thanks

- Ioi

On 08/23/2013 01:23 PM, Calvin Cheung wrote:
> Hi Misha,
>
> Thanks for reviewing the test case.
>
> All,
>
> I've updated the webrev with the one-line change in classLoader.cpp.
> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>
> thanks,
> Calvin
>
> On 8/23/2013 11:45 AM, Mikhailo Seledtsov wrote:
>> Hi Calvin,
>>
>>  I only reviewed the test portion. It looks good to me.
>>
>> Misha
>>
>> On 8/23/2013 1:53 PM, Calvin Cheung wrote:
>>> On 8/22/2013 11:54 PM, David Holmes wrote:
>>>> On 23/08/2013 4:05 PM, Calvin Cheung wrote:
>>>>> On 8/22/2013 5:21 PM, David Holmes wrote:
>>>>>> Hi Calvin,
>>>>>>
>>>>>> I'm having trouble keeping track of this one ...
>>>>>>
>>>>>> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>>>>>>> Note that the synopsis of the bug has been changed from:
>>>>>>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0
>>>>>>> Build 4"
>>>>>>>
>>>>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>>>>>>
>>>>>>> I've included the suggestions from Coleen and Ioi in this 
>>>>>>> version of
>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>>
>>>>>> I don't understand your _has_error logic:
>>>>>>
>>>>>>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>>>>  326   if (cpe == NULL) {
>>>>>>  327     _has_error = true;
>>>>>>  328     return NULL;
>>>>>>
>>>>>> we will only hit line 327 if resolve_entry returns NULL _without_
>>>>>> there being an exception pending. How does that occur? What is
>>>>>> different about the two cases regardless?
>>>>> The _has_error flag was suggested by Ioi and is to avoid opening the
>>>>> invalid jar file again.
>>>>
>>>> Can't we just remove it from the classpath representation?
>>> I think it can be done if the error happens during vm initialization.
>>> But for this test scenario, the error happens after vm init.
>>> Perhaps this should be addressed as a separate bug fix?
>>>>
>>>>> The call sequence is as follows:
>>>>> ClassLoader::load_classfile()
>>>>>      -> LazyClassPathEntry::open_stream()
>>>>>          -> LazyClassPathEntry::resolve_entry()
>>>>>              -> ClassLoader::create_class_path_entry()
>>>>>
>>>>> For second time, it'll return NULL without calling resolve_entry() 
>>>>> again.
>>>>>
>>>>> The LazyClassPathEntry instance is instantiated by the following 
>>>>> calls:
>>>>> ClassLoader::setup_bootstrap_search_path()
>>>>>      ->ClassLoader::update_class_path_entry_list()
>>>>>          ->ClassLoader::create_class_path_entry(path, &st,
>>>>> LazyBootClassLoader, CHECK)
>>>>>
>>>>> LazyBootClassLoader is set to true by default.
>>>>
>>>> Sorry but I don't see how that answers my question. Based on the 
>>>> below there isn't a second time because the first time will cause 
>>>> the pending exception which will terminate the VM. Even if we dont 
>>>> terminate and somehow call this again, we didn't set _has_error the 
>>>> first time anyway! ???
>>> Let's not confused with the classes we're preloading during vm 
>>> initialization and the applications classes after vm initialization.
>>>
>>> Consider the following test case:
>>> public class test3 {
>>>     public static void main(String[] args) {
>>>         try {
>>>             //Class cls = Class.forName("javax.crypto.KeyGenerator");
>>>             //System.out.println("Class = " + cls.getName());
>>>             Class cls = Class.forName("xxx");
>>>             System.out.println("Class = " + cls.getName());
>>>         } catch (ClassNotFoundException cnfe) {
>>>             cnfe.printStackTrace();
>>>         }
>>>         try {
>>>             Class cls2 = Class.forName("yyy");
>>>             System.out.println("Class = " + cls2.getName());
>>>         } catch (ClassNotFoundException cnfe) {
>>>             cnfe.printStackTrace();
>>>         }
>>>     }
>>> }
>>>
>>> Let's say we have a dummy.jar with 0-byte and test3.class in the 
>>> same directory.
>>> And command line as follows:
>>> java -Xbootclasspath/a:dummy.jar -cp . test3
>>>
>>> During vm init. (as in the above 
>>> ClassLoader::setup_bootstrap_search_path() call sequence), there's 
>>> no problem because vm doesn't need to read dummy.jar as all other 
>>> preload classes can be found in jdk's jar files (rt.jar, jce.jar, 
>>> etc.) (Note: this isn't the case with 7u25, we were trying to 
>>> preload a non-existing class, please refer to my comment in the bug 
>>> report.)
>>>
>>> When vm tries to load the class for the test case (test3.class), 
>>> it'll call into LazyClassPathEntry::open_stream(). This is the first 
>>> time resolve_entry() returns NULL and the _has_error flag will be 
>>> set to true. The next time vm will try to load xxx.class. Since 
>>> _has_error was set to NULL, it will return NULL without calling 
>>> resolve_entry(). Same story for the third time for the yyy.class.
>>>
>>> call stack as follows:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, const 
>>> stat * st, bool lazy, Thread * __the_thread__) Line 515    C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry(Thread * 
>>> __the_thread__)  Line 304 + 0x19 bytes    C++
>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name, 
>>> Thread * __the_thread__)  Line 325 + 0xc bytes    C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 909 + 0x1b bytes    C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1301 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 237 + 0x23 bytes    C++
>>> >    jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>>> name)  Line 770 + 0x12 bytes    C++
>>>      java.dll!70671e8c()
>>>
>>> I've just noticed that there's a slight error in my change in line 
>>> #325 of classLoader.cpp:
>>>
>>> ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>
>>> should be
>>>
>>> ClassPathEntry* cpe = resolve_entry(THREAD);
>>>
>>> Otherwise, it'll skip the rest of the statements.
>>> I'll update webrev shortly.
>>>
>>>>
>>>>>>
>>>>>> And we still have this sequence:
>>>>>>
>>>>>> void ClassLoader::initialize() {
>>>>>>   assert(_package_hash_table == NULL, "should have been 
>>>>>> initialized by
>>>>>> now.");
>>>>>>   EXCEPTION_MARK;
>>>>>>   ...
>>>>>>   setup_bootstrap_search_path();
>>>>>>     -> update_class_path_entry_list(path, false);
>>>>>>       ->  create_class_path_entry((char *)path, st, &new_entry,
>>>>>> LazyBootClassLoader, CHECK);
>>>>> As mentioned above, this call sequence is for instantiating the
>>>>> LazyClassPathEntry instances.
>>>>>>
>>>>>> So if we return after the call to create_class_path_entry with an
>>>>>> exception pending we will crash when we hit the EXCEPTION_MARK. Why
>>>>>> doesn't this happen?
>>>>> During vm initilization, it's ok to have exception pending. The
>>>>> destructor of ExceptionMark is as follows:
>>>>> ExceptionMark::~ExceptionMark() {
>>>>>    if (_thread->has_pending_exception()) {
>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>> recursion
>>>>>      if (is_init_completed()) {
>>>>>        exception->print();
>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>> exceptions");
>>>>>      } else {
>>>>>        vm_exit_during_initialization(exception);
>>>>>      }
>>>>>    }
>>>>> }
>>>>>
>>>>> So if is_init_completed() is false, it'll just print an error and 
>>>>> exit.
>>>>
>>>> So we do hit it - ok. So this yet another place where the VM should 
>>>> not abort during initialization.
>>> Yes and this is for preloading class scenario during vm init.
>>> IMHO, I don't think we should change the behavior now.
>>>
>>> thanks,
>>> Calvin
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Tests:
>>>>>>>      jprt
>>>>>>>          (in progress - only about 30 tests left on the windows
>>>>>>> platforms, no failure so far;
>>>>>>>           a previous run with only Coleen's suggestions was 
>>>>>>> successful)
>>>>>>>
>>>>>>>      vm.quick.testlist on linux_x64
>>>>>>>
>>>>>>> Please review.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Calvin
>>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/7ee7ac5f/attachment.html 

From calvin.cheung at oracle.com  Mon Aug 26 11:27:58 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Mon, 26 Aug 2013 11:27:58 -0700
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <521B969E.9020609@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
	<5216FBA9.50807@oracle.com> <5217072C.5020106@oracle.com>
	<5217A19F.7020103@oracle.com> <5217ADDD.9090604@oracle.com>
	<5217C4A8.8000000@oracle.com> <521B969E.9020609@oracle.com>
Message-ID: <521B9E2E.1030708@oracle.com>

Coleen,

Thanks for your review.

Calvin
On 8/26/2013 10:55 AM, Coleen Phillimore wrote:
>
> Calvin,
>
> The code change looks great.  Thank you for doing the cleanups also.
>
> Coleen
>
> On 8/23/2013 4:23 PM, Calvin Cheung wrote:
>> Hi Misha,
>>
>> Thanks for reviewing the test case.
>>
>> All,
>>
>> I've updated the webrev with the one-line change in classLoader.cpp.
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>
>> thanks,
>> Calvin
>>
>> On 8/23/2013 11:45 AM, Mikhailo Seledtsov wrote:
>>> Hi Calvin,
>>>
>>>  I only reviewed the test portion. It looks good to me.
>>>
>>> Misha
>>>
>>> On 8/23/2013 1:53 PM, Calvin Cheung wrote:
>>>> On 8/22/2013 11:54 PM, David Holmes wrote:
>>>>> On 23/08/2013 4:05 PM, Calvin Cheung wrote:
>>>>>> On 8/22/2013 5:21 PM, David Holmes wrote:
>>>>>>> Hi Calvin,
>>>>>>>
>>>>>>> I'm having trouble keeping track of this one ...
>>>>>>>
>>>>>>> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>>>>>>>> Note that the synopsis of the bug has been changed from:
>>>>>>>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0
>>>>>>>> Build 4"
>>>>>>>>
>>>>>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>>>>>>>
>>>>>>>> I've included the suggestions from Coleen and Ioi in this 
>>>>>>>> version of
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>>>
>>>>>>> I don't understand your _has_error logic:
>>>>>>>
>>>>>>>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>>>>>  326   if (cpe == NULL) {
>>>>>>>  327     _has_error = true;
>>>>>>>  328     return NULL;
>>>>>>>
>>>>>>> we will only hit line 327 if resolve_entry returns NULL _without_
>>>>>>> there being an exception pending. How does that occur? What is
>>>>>>> different about the two cases regardless?
>>>>>> The _has_error flag was suggested by Ioi and is to avoid opening the
>>>>>> invalid jar file again.
>>>>>
>>>>> Can't we just remove it from the classpath representation?
>>>> I think it can be done if the error happens during vm initialization.
>>>> But for this test scenario, the error happens after vm init.
>>>> Perhaps this should be addressed as a separate bug fix?
>>>>>
>>>>>> The call sequence is as follows:
>>>>>> ClassLoader::load_classfile()
>>>>>>      -> LazyClassPathEntry::open_stream()
>>>>>>          -> LazyClassPathEntry::resolve_entry()
>>>>>>              -> ClassLoader::create_class_path_entry()
>>>>>>
>>>>>> For second time, it'll return NULL without calling 
>>>>>> resolve_entry() again.
>>>>>>
>>>>>> The LazyClassPathEntry instance is instantiated by the following 
>>>>>> calls:
>>>>>> ClassLoader::setup_bootstrap_search_path()
>>>>>>      ->ClassLoader::update_class_path_entry_list()
>>>>>> ->ClassLoader::create_class_path_entry(path, &st,
>>>>>> LazyBootClassLoader, CHECK)
>>>>>>
>>>>>> LazyBootClassLoader is set to true by default.
>>>>>
>>>>> Sorry but I don't see how that answers my question. Based on the 
>>>>> below there isn't a second time because the first time will cause 
>>>>> the pending exception which will terminate the VM. Even if we dont 
>>>>> terminate and somehow call this again, we didn't set _has_error 
>>>>> the first time anyway! ???
>>>> Let's not confused with the classes we're preloading during vm 
>>>> initialization and the applications classes after vm initialization.
>>>>
>>>> Consider the following test case:
>>>> public class test3 {
>>>>     public static void main(String[] args) {
>>>>         try {
>>>>             //Class cls = Class.forName("javax.crypto.KeyGenerator");
>>>>             //System.out.println("Class = " + cls.getName());
>>>>             Class cls = Class.forName("xxx");
>>>>             System.out.println("Class = " + cls.getName());
>>>>         } catch (ClassNotFoundException cnfe) {
>>>>             cnfe.printStackTrace();
>>>>         }
>>>>         try {
>>>>             Class cls2 = Class.forName("yyy");
>>>>             System.out.println("Class = " + cls2.getName());
>>>>         } catch (ClassNotFoundException cnfe) {
>>>>             cnfe.printStackTrace();
>>>>         }
>>>>     }
>>>> }
>>>>
>>>> Let's say we have a dummy.jar with 0-byte and test3.class in the 
>>>> same directory.
>>>> And command line as follows:
>>>> java -Xbootclasspath/a:dummy.jar -cp . test3
>>>>
>>>> During vm init. (as in the above 
>>>> ClassLoader::setup_bootstrap_search_path() call sequence), there's 
>>>> no problem because vm doesn't need to read dummy.jar as all other 
>>>> preload classes can be found in jdk's jar files (rt.jar, jce.jar, 
>>>> etc.) (Note: this isn't the case with 7u25, we were trying to 
>>>> preload a non-existing class, please refer to my comment in the bug 
>>>> report.)
>>>>
>>>> When vm tries to load the class for the test case (test3.class), 
>>>> it'll call into LazyClassPathEntry::open_stream(). This is the 
>>>> first time resolve_entry() returns NULL and the _has_error flag 
>>>> will be set to true. The next time vm will try to load xxx.class. 
>>>> Since _has_error was set to NULL, it will return NULL without 
>>>> calling resolve_entry(). Same story for the third time for the 
>>>> yyy.class.
>>>>
>>>> call stack as follows:
>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, 
>>>> const stat * st, bool lazy, Thread * __the_thread__)  Line 515    C++
>>>>      jvm.dll!LazyClassPathEntry::resolve_entry(Thread * 
>>>> __the_thread__)  Line 304 + 0x19 bytes    C++
>>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name, 
>>>> Thread * __the_thread__)  Line 325 + 0xc bytes C++
>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>> __the_thread__)  Line 909 + 0x1b bytes    C++
>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>> class_name, Handle class_loader, Thread * __the_thread__)  Line 
>>>> 1301 + 0x14 bytes    C++
>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Thread * __the_thread__)  Line 237 + 0x23 bytes    C++
>>>> >    jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char 
>>>> * name)  Line 770 + 0x12 bytes    C++
>>>>      java.dll!70671e8c()
>>>>
>>>> I've just noticed that there's a slight error in my change in line 
>>>> #325 of classLoader.cpp:
>>>>
>>>> ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>>
>>>> should be
>>>>
>>>> ClassPathEntry* cpe = resolve_entry(THREAD);
>>>>
>>>> Otherwise, it'll skip the rest of the statements.
>>>> I'll update webrev shortly.
>>>>
>>>>>
>>>>>>>
>>>>>>> And we still have this sequence:
>>>>>>>
>>>>>>> void ClassLoader::initialize() {
>>>>>>>   assert(_package_hash_table == NULL, "should have been 
>>>>>>> initialized by
>>>>>>> now.");
>>>>>>>   EXCEPTION_MARK;
>>>>>>>   ...
>>>>>>>   setup_bootstrap_search_path();
>>>>>>>     -> update_class_path_entry_list(path, false);
>>>>>>>       ->  create_class_path_entry((char *)path, st, &new_entry,
>>>>>>> LazyBootClassLoader, CHECK);
>>>>>> As mentioned above, this call sequence is for instantiating the
>>>>>> LazyClassPathEntry instances.
>>>>>>>
>>>>>>> So if we return after the call to create_class_path_entry with an
>>>>>>> exception pending we will crash when we hit the EXCEPTION_MARK. Why
>>>>>>> doesn't this happen?
>>>>>> During vm initilization, it's ok to have exception pending. The
>>>>>> destructor of ExceptionMark is as follows:
>>>>>> ExceptionMark::~ExceptionMark() {
>>>>>>    if (_thread->has_pending_exception()) {
>>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>>> recursion
>>>>>>      if (is_init_completed()) {
>>>>>>        exception->print();
>>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>>> exceptions");
>>>>>>      } else {
>>>>>>        vm_exit_during_initialization(exception);
>>>>>>      }
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>> So if is_init_completed() is false, it'll just print an error and 
>>>>>> exit.
>>>>>
>>>>> So we do hit it - ok. So this yet another place where the VM 
>>>>> should not abort during initialization.
>>>> Yes and this is for preloading class scenario during vm init.
>>>> IMHO, I don't think we should change the behavior now.
>>>>
>>>> thanks,
>>>> Calvin
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> thanks,
>>>>>> Calvin
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> Tests:
>>>>>>>>      jprt
>>>>>>>>          (in progress - only about 30 tests left on the windows
>>>>>>>> platforms, no failure so far;
>>>>>>>>           a previous run with only Coleen's suggestions was 
>>>>>>>> successful)
>>>>>>>>
>>>>>>>>      vm.quick.testlist on linux_x64
>>>>>>>>
>>>>>>>> Please review.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Calvin
>>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/0575dff8/attachment-0001.html 

From calvin.cheung at oracle.com  Mon Aug 26 11:28:29 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Mon, 26 Aug 2013 11:28:29 -0700
Subject: RFR 8020675: invalid jar file in the bootclasspath could lead
	to jvm fatal error
In-Reply-To: <521B99CB.6050202@oracle.com>
References: <521696F9.5040403@oracle.com> <5216AAEF.5080101@oracle.com>
	<5216FBA9.50807@oracle.com> <5217072C.5020106@oracle.com>
	<5217A19F.7020103@oracle.com> <5217ADDD.9090604@oracle.com>
	<5217C4A8.8000000@oracle.com> <521B99CB.6050202@oracle.com>
Message-ID: <521B9E4D.2030007@oracle.com>

Ioi,

Thanks for your review.

Calvin

On 8/26/2013 11:09 AM, Ioi Lam wrote:
> Calvin,
>
> Looks good.
>
> Thanks
>
> - Ioi
>
> On 08/23/2013 01:23 PM, Calvin Cheung wrote:
>> Hi Misha,
>>
>> Thanks for reviewing the test case.
>>
>> All,
>>
>> I've updated the webrev with the one-line change in classLoader.cpp.
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>
>> thanks,
>> Calvin
>>
>> On 8/23/2013 11:45 AM, Mikhailo Seledtsov wrote:
>>> Hi Calvin,
>>>
>>>  I only reviewed the test portion. It looks good to me.
>>>
>>> Misha
>>>
>>> On 8/23/2013 1:53 PM, Calvin Cheung wrote:
>>>> On 8/22/2013 11:54 PM, David Holmes wrote:
>>>>> On 23/08/2013 4:05 PM, Calvin Cheung wrote:
>>>>>> On 8/22/2013 5:21 PM, David Holmes wrote:
>>>>>>> Hi Calvin,
>>>>>>>
>>>>>>> I'm having trouble keeping track of this one ...
>>>>>>>
>>>>>>> On 23/08/2013 8:55 AM, Calvin Cheung wrote:
>>>>>>>> Note that the synopsis of the bug has been changed from:
>>>>>>>> "Trying to print to a pdf file with PDFill PDF&Image Writer 10.0
>>>>>>>> Build 4"
>>>>>>>>
>>>>>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8020675
>>>>>>>>
>>>>>>>> I've included the suggestions from Coleen and Ioi in this 
>>>>>>>> version of
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>>>
>>>>>>> I don't understand your _has_error logic:
>>>>>>>
>>>>>>>  325   ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>>>>>  326   if (cpe == NULL) {
>>>>>>>  327     _has_error = true;
>>>>>>>  328     return NULL;
>>>>>>>
>>>>>>> we will only hit line 327 if resolve_entry returns NULL _without_
>>>>>>> there being an exception pending. How does that occur? What is
>>>>>>> different about the two cases regardless?
>>>>>> The _has_error flag was suggested by Ioi and is to avoid opening the
>>>>>> invalid jar file again.
>>>>>
>>>>> Can't we just remove it from the classpath representation?
>>>> I think it can be done if the error happens during vm initialization.
>>>> But for this test scenario, the error happens after vm init.
>>>> Perhaps this should be addressed as a separate bug fix?
>>>>>
>>>>>> The call sequence is as follows:
>>>>>> ClassLoader::load_classfile()
>>>>>>      -> LazyClassPathEntry::open_stream()
>>>>>>          -> LazyClassPathEntry::resolve_entry()
>>>>>>              -> ClassLoader::create_class_path_entry()
>>>>>>
>>>>>> For second time, it'll return NULL without calling 
>>>>>> resolve_entry() again.
>>>>>>
>>>>>> The LazyClassPathEntry instance is instantiated by the following 
>>>>>> calls:
>>>>>> ClassLoader::setup_bootstrap_search_path()
>>>>>>      ->ClassLoader::update_class_path_entry_list()
>>>>>> ->ClassLoader::create_class_path_entry(path, &st,
>>>>>> LazyBootClassLoader, CHECK)
>>>>>>
>>>>>> LazyBootClassLoader is set to true by default.
>>>>>
>>>>> Sorry but I don't see how that answers my question. Based on the 
>>>>> below there isn't a second time because the first time will cause 
>>>>> the pending exception which will terminate the VM. Even if we dont 
>>>>> terminate and somehow call this again, we didn't set _has_error 
>>>>> the first time anyway! ???
>>>> Let's not confused with the classes we're preloading during vm 
>>>> initialization and the applications classes after vm initialization.
>>>>
>>>> Consider the following test case:
>>>> public class test3 {
>>>>     public static void main(String[] args) {
>>>>         try {
>>>>             //Class cls = Class.forName("javax.crypto.KeyGenerator");
>>>>             //System.out.println("Class = " + cls.getName());
>>>>             Class cls = Class.forName("xxx");
>>>>             System.out.println("Class = " + cls.getName());
>>>>         } catch (ClassNotFoundException cnfe) {
>>>>             cnfe.printStackTrace();
>>>>         }
>>>>         try {
>>>>             Class cls2 = Class.forName("yyy");
>>>>             System.out.println("Class = " + cls2.getName());
>>>>         } catch (ClassNotFoundException cnfe) {
>>>>             cnfe.printStackTrace();
>>>>         }
>>>>     }
>>>> }
>>>>
>>>> Let's say we have a dummy.jar with 0-byte and test3.class in the 
>>>> same directory.
>>>> And command line as follows:
>>>> java -Xbootclasspath/a:dummy.jar -cp . test3
>>>>
>>>> During vm init. (as in the above 
>>>> ClassLoader::setup_bootstrap_search_path() call sequence), there's 
>>>> no problem because vm doesn't need to read dummy.jar as all other 
>>>> preload classes can be found in jdk's jar files (rt.jar, jce.jar, 
>>>> etc.) (Note: this isn't the case with 7u25, we were trying to 
>>>> preload a non-existing class, please refer to my comment in the bug 
>>>> report.)
>>>>
>>>> When vm tries to load the class for the test case (test3.class), 
>>>> it'll call into LazyClassPathEntry::open_stream(). This is the 
>>>> first time resolve_entry() returns NULL and the _has_error flag 
>>>> will be set to true. The next time vm will try to load xxx.class. 
>>>> Since _has_error was set to NULL, it will return NULL without 
>>>> calling resolve_entry(). Same story for the third time for the 
>>>> yyy.class.
>>>>
>>>> call stack as follows:
>>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, 
>>>> const stat * st, bool lazy, Thread * __the_thread__)  Line 515    C++
>>>>      jvm.dll!LazyClassPathEntry::resolve_entry(Thread * 
>>>> __the_thread__)  Line 304 + 0x19 bytes    C++
>>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name, 
>>>> Thread * __the_thread__)  Line 325 + 0xc bytes C++
>>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>>> __the_thread__)  Line 909 + 0x1b bytes    C++
>>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>>> class_name, Handle class_loader, Thread * __the_thread__)  Line 
>>>> 1301 + 0x14 bytes    C++
>>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Handle class_loader, Handle protection_domain, Thread * 
>>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>>> Thread * __the_thread__)  Line 237 + 0x23 bytes    C++
>>>> >    jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char 
>>>> * name)  Line 770 + 0x12 bytes    C++
>>>>      java.dll!70671e8c()
>>>>
>>>> I've just noticed that there's a slight error in my change in line 
>>>> #325 of classLoader.cpp:
>>>>
>>>> ClassPathEntry* cpe = resolve_entry(CHECK_NULL);
>>>>
>>>> should be
>>>>
>>>> ClassPathEntry* cpe = resolve_entry(THREAD);
>>>>
>>>> Otherwise, it'll skip the rest of the statements.
>>>> I'll update webrev shortly.
>>>>
>>>>>
>>>>>>>
>>>>>>> And we still have this sequence:
>>>>>>>
>>>>>>> void ClassLoader::initialize() {
>>>>>>>   assert(_package_hash_table == NULL, "should have been 
>>>>>>> initialized by
>>>>>>> now.");
>>>>>>>   EXCEPTION_MARK;
>>>>>>>   ...
>>>>>>>   setup_bootstrap_search_path();
>>>>>>>     -> update_class_path_entry_list(path, false);
>>>>>>>       ->  create_class_path_entry((char *)path, st, &new_entry,
>>>>>>> LazyBootClassLoader, CHECK);
>>>>>> As mentioned above, this call sequence is for instantiating the
>>>>>> LazyClassPathEntry instances.
>>>>>>>
>>>>>>> So if we return after the call to create_class_path_entry with an
>>>>>>> exception pending we will crash when we hit the EXCEPTION_MARK. Why
>>>>>>> doesn't this happen?
>>>>>> During vm initilization, it's ok to have exception pending. The
>>>>>> destructor of ExceptionMark is as follows:
>>>>>> ExceptionMark::~ExceptionMark() {
>>>>>>    if (_thread->has_pending_exception()) {
>>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>>> recursion
>>>>>>      if (is_init_completed()) {
>>>>>>        exception->print();
>>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>>> exceptions");
>>>>>>      } else {
>>>>>>        vm_exit_during_initialization(exception);
>>>>>>      }
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>> So if is_init_completed() is false, it'll just print an error and 
>>>>>> exit.
>>>>>
>>>>> So we do hit it - ok. So this yet another place where the VM 
>>>>> should not abort during initialization.
>>>> Yes and this is for preloading class scenario during vm init.
>>>> IMHO, I don't think we should change the behavior now.
>>>>
>>>> thanks,
>>>> Calvin
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> thanks,
>>>>>> Calvin
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> Tests:
>>>>>>>>      jprt
>>>>>>>>          (in progress - only about 30 tests left on the windows
>>>>>>>> platforms, no failure so far;
>>>>>>>>           a previous run with only Coleen's suggestions was 
>>>>>>>> successful)
>>>>>>>>
>>>>>>>>      vm.quick.testlist on linux_x64
>>>>>>>>
>>>>>>>> Please review.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Calvin
>>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/6e8551e3/attachment.html 

From lois.foltan at oracle.com  Mon Aug 26 11:36:30 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 26 Aug 2013 14:36:30 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS; hs_err_pid
	file produced
Message-ID: <521BA02E.6080901@oracle.com>

Please review the following fix:

Internal webrev:

    http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/

Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
          runtime/6878713/Test6878713.sh fails on mac

     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
https://bugs.openjdk.java.net/browse/JDK-8022140

Summary of fix:
     On MacOS, currently Hotspot is built specifying the -fcheck-new 
command line option to the llvm-g++ compiler.
     The -fcheck-new option directs the compiler to "check that the 
pointer returned by |operator new| is non-null
      before attempting to modify the storage allocated."  The clang++ 
compiler does not support the
      -fcheck-new option.  To obtain similiar functionality when 
building Hotspot with clang++, empty exception
      throw() specifications must be added to all user-defined operator 
new()'s.

Tests:

      Solaris: built fastdebug & product images
      Linux: built fastdebug & product images
      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
                     built fastdebug & product images using clang++ - 
ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
      Windows:  built fastdebug & product images with VS2010

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/77fcf2b4/attachment-0001.html 

From david.r.chase at oracle.com  Mon Aug 26 13:08:32 2013
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 26 Aug 2013 16:08:32 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <E4F45E47-2571-46B6-BF33-4AA554286089@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
	<94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
	<F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>
	<52119939.50205@oracle.com>
	<2415DA74-C2C1-4B34-8598-9A0072FA7BA9@oracle.com>
	<925B8B0B-E7A9-4934-B8F8-FAABB6492B01@oracle.com>
	<727C0BA7-6E86-4FBB-A1CB-8E7670A27214@oracle.com>
	<E97C13DD-AC22-45B1-9CC1-1FD4A044B95C@oracle.com>
	<E4F45E47-2571-46B6-BF33-4AA554286089@oracle.com>
Message-ID: <347DC862-913F-424E-A62F-C576F04F43B8@oracle.com>

A question on this point, where we may be getting tangled up by multiple negation:

you say "you can have an overpass method, which does not require a vtable entry,"
so is an overpass method "final", contrary to the current code?

David

On 2013-08-26, at 1:22 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:

> 2. In method.cpp in is_final_method
> Could you please delete the comment lies 513-514
> "Should return true for private methods also, since there is no way to override them?"
> 
> Yes, you do not override private methods. However, this call is used to determine if you
> need a vtable entry. Private methods always get a vtable entry to handle backward compatibility
> with classes - i.e. you can have the same name of a private method local to your class and also
> inherit a method of from your superclass, which will get inherited around the private method, by
> your child.
> 
> And yes, you can have an overpass method, which does not require a vtable entry,
> so the "can this happen?" answer is yes - so you can remove the question.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/88829d45/signature.asc 

From harold.seigel at oracle.com  Mon Aug 26 13:18:12 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Mon, 26 Aug 2013 16:18:12 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521BA02E.6080901@oracle.com>
References: <521BA02E.6080901@oracle.com>
Message-ID: <521BB804.4050307@oracle.com>

Hi Lois,

The changes look good.

Harold

On 8/26/2013 2:36 PM, Lois Foltan wrote:
> Please review the following fix:
>
> Internal webrev:
>
> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>
> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>          runtime/6878713/Test6878713.sh fails on mac
>
>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
> https://bugs.openjdk.java.net/browse/JDK-8022140
>
> Summary of fix:
>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
> command line option to the llvm-g++ compiler.
>     The -fcheck-new option directs the compiler to "check that the 
> pointer returned by |operator new| is non-null
>      before attempting to modify the storage allocated."  The clang++ 
> compiler does not support the
>      -fcheck-new option.  To obtain similiar functionality when 
> building Hotspot with clang++, empty exception
>      throw() specifications must be added to all user-defined operator 
> new()'s.
>
> Tests:
>
>      Solaris: built fastdebug & product images
>      Linux: built fastdebug & product images
>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>                     built fastdebug & product images using clang++ - 
> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>      Windows:  built fastdebug & product images with VS2010
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/0e793ac2/attachment.html 

From coleen.phillimore at oracle.com  Mon Aug 26 13:18:24 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 26 Aug 2013 16:18:24 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521BA02E.6080901@oracle.com>
References: <521BA02E.6080901@oracle.com>
Message-ID: <521BB810.8080308@oracle.com>


Looks good, Lois.
thanks!
Coleen

On 8/26/2013 2:36 PM, Lois Foltan wrote:
> Please review the following fix:
>
> Internal webrev:
>
> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>
> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>          runtime/6878713/Test6878713.sh fails on mac
>
>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
> https://bugs.openjdk.java.net/browse/JDK-8022140
>
> Summary of fix:
>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
> command line option to the llvm-g++ compiler.
>     The -fcheck-new option directs the compiler to "check that the 
> pointer returned by |operator new| is non-null
>      before attempting to modify the storage allocated."  The clang++ 
> compiler does not support the
>      -fcheck-new option.  To obtain similiar functionality when 
> building Hotspot with clang++, empty exception
>      throw() specifications must be added to all user-defined operator 
> new()'s.
>
> Tests:
>
>      Solaris: built fastdebug & product images
>      Linux: built fastdebug & product images
>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>                     built fastdebug & product images using clang++ - 
> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>      Windows:  built fastdebug & product images with VS2010
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/d436e7bf/attachment.html 

From karen.kinnear at oracle.com  Mon Aug 26 13:19:25 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 26 Aug 2013 16:19:25 -0400
Subject: RFR (L) : 8014013 : CallInfo structure no longer accurately
	reports the result of a LinkResolver operation
In-Reply-To: <347DC862-913F-424E-A62F-C576F04F43B8@oracle.com>
References: <191C61A2-6E5A-4EE3-9F40-B6C977C92BD6@oracle.com>
	<A9F7ED21-1C4A-4D52-909B-906FBCE487CD@oracle.com>
	<6C3948E7-7F89-4C27-BDCE-ABF9534E7D44@oracle.com>
	<858DD708-AA28-4997-BA3C-65BE5248B635@oracle.com>
	<94224102-AC0E-42F3-BF9D-79DF904FD53D@oracle.com>
	<F91808EB-B218-4476-8DD6-C40D421E2B64@oracle.com>
	<52119939.50205@oracle.com>
	<2415DA74-C2C1-4B34-8598-9A0072FA7BA9@oracle.com>
	<925B8B0B-E7A9-4934-B8F8-FAABB6492B01@oracle.com>
	<727C0BA7-6E86-4FBB-A1CB-8E7670A27214@oracle.com>
	<E97C13DD-AC22-45B1-9CC1-1FD4A044B95C@oracle.com>
	<E4F45E47-2571-46B6-BF33-4AA554286089@oracle.com>
	<347DC862-913F-424E-A62F-C576F04F43B8@oracle.com>
Message-ID: <C3888BDB-DABD-40B3-8D83-7889513EB58C@oracle.com>

An overpass method is a method created to bridge to a default method in an interface today.
An overpass method does NOT require a vtable entry to be created because we only create
them with names matching current miranda methods, so the overpass method will re-use
the miranda method's vtable entry. 

I should have been clearer - an overpass method does not require a NEW vtable entry,
it does use a vtable entry. 

hth,
Karen

On Aug 26, 2013, at 4:08 PM, David Chase wrote:

> A question on this point, where we may be getting tangled up by multiple negation:
> 
> you say "you can have an overpass method, which does not require a vtable entry,"
> so is an overpass method "final", contrary to the current code?
> 
> David
> 
> On 2013-08-26, at 1:22 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
>> 2. In method.cpp in is_final_method
>> Could you please delete the comment lies 513-514
>> "Should return true for private methods also, since there is no way to override them?"
>> 
>> Yes, you do not override private methods. However, this call is used to determine if you
>> need a vtable entry. Private methods always get a vtable entry to handle backward compatibility
>> with classes - i.e. you can have the same name of a private method local to your class and also
>> inherit a method of from your superclass, which will get inherited around the private method, by
>> your child.
>> 
>> And yes, you can have an overpass method, which does not require a vtable entry,
>> so the "can this happen?" answer is yes - so you can remove the question.
> 


From stefan.karlsson at oracle.com  Mon Aug 26 15:53:40 2013
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Mon, 26 Aug 2013 22:53:40 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130826225348.D5BB548B88@hg.openjdk.java.net>

Changeset: 4c84d351cca9
Author:    stefank
Date:      2013-08-16 13:22 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4c84d351cca9

8007074: SIGSEGV at ParMarkBitMap::verify_clear()
Summary: Replace the broken large pages implementation on Linux. New flag: -XX:+UseTransparentHugePages - Linux specific flag to turn on transparent huge page hinting with madvise(..., MAP_HUGETLB). Changed behavior: -XX:+UseLargePages - tries to use -XX:+UseTransparentHugePages before trying other large pages implementations (on Linux). Changed behavior: -XX:+UseHugeTLBFS - Use upfront allocation of Large Pages instead of using the broken implementation to dynamically committing large pages. Changed behavior: -XX:LargePageSizeInBytes - Turned off the ability to use this flag on Linux and provides warning to user if set to a value different than the OS chosen large page size. Changed behavior: Setting no large page size - Now defaults to use -XX:UseTransparentHugePages if the OS supports it. Previously, -XX:+UseHugeTLBFS was chosen if the OS was configured to use large pages.
Reviewed-by: tschatzl, dcubed, brutisso

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/globals_linux.hpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp
! src/share/vm/services/memTracker.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 21ffbaa691b5
Author:    stefank
Date:      2013-08-26 07:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/21ffbaa691b5

Merge

! src/share/vm/prims/jni.cpp


From lois.foltan at oracle.com  Mon Aug 26 18:04:19 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 26 Aug 2013 21:04:19 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521BB804.4050307@oracle.com>
References: <521BA02E.6080901@oracle.com> <521BB804.4050307@oracle.com>
Message-ID: <521BFB13.4080605@oracle.com>

Hi Harold,
Thanks for the review.
Lois

On 8/26/2013 4:18 PM, harold seigel wrote:
> Hi Lois,
>
> The changes look good.
>
> Harold
>
> On 8/26/2013 2:36 PM, Lois Foltan wrote:
>> Please review the following fix:
>>
>> Internal webrev:
>>
>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>
>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>          runtime/6878713/Test6878713.sh fails on mac
>>
>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>
>> Summary of fix:
>>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
>> command line option to the llvm-g++ compiler.
>>     The -fcheck-new option directs the compiler to "check that the 
>> pointer returned by |operator new| is non-null
>>      before attempting to modify the storage allocated."  The clang++ 
>> compiler does not support the
>>      -fcheck-new option.  To obtain similiar functionality when 
>> building Hotspot with clang++, empty exception
>>      throw() specifications must be added to all user-defined 
>> operator new()'s.
>>
>> Tests:
>>
>>      Solaris: built fastdebug & product images
>>      Linux: built fastdebug & product images
>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>                     built fastdebug & product images using clang++ - 
>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>      Windows:  built fastdebug & product images with VS2010
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/d7940b59/attachment-0001.html 

From lois.foltan at oracle.com  Mon Aug 26 18:04:42 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 26 Aug 2013 21:04:42 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521BB810.8080308@oracle.com>
References: <521BA02E.6080901@oracle.com> <521BB810.8080308@oracle.com>
Message-ID: <521BFB2A.8030704@oracle.com>

Hi Coleen,
Thanks for the review.
Lois

On 8/26/2013 4:18 PM, Coleen Phillimore wrote:
>
> Looks good, Lois.
> thanks!
> Coleen
>
> On 8/26/2013 2:36 PM, Lois Foltan wrote:
>> Please review the following fix:
>>
>> Internal webrev:
>>
>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>
>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>          runtime/6878713/Test6878713.sh fails on mac
>>
>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>
>> Summary of fix:
>>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
>> command line option to the llvm-g++ compiler.
>>     The -fcheck-new option directs the compiler to "check that the 
>> pointer returned by |operator new| is non-null
>>      before attempting to modify the storage allocated."  The clang++ 
>> compiler does not support the
>>      -fcheck-new option.  To obtain similiar functionality when 
>> building Hotspot with clang++, empty exception
>>      throw() specifications must be added to all user-defined 
>> operator new()'s.
>>
>> Tests:
>>
>>      Solaris: built fastdebug & product images
>>      Linux: built fastdebug & product images
>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>                     built fastdebug & product images using clang++ - 
>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>      Windows:  built fastdebug & product images with VS2010
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/7e2d4446/attachment.html 

From ioi.lam at oracle.com  Mon Aug 26 18:17:42 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 26 Aug 2013 18:17:42 -0700
Subject: RFR (XXS) 8020622 - Visual Studio 2012 project creation for hotspot
Message-ID: <521BFE36.2020708@oracle.com>

Please review a very small fix:

http://cr.openjdk.java.net/~iklam/8020622/vs2012_proj_001/

Bug: create.bat on Windows failed to create project file for Visual 
Studio 2012

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

Summary of fix:

     Treat VS2012 as VS2010. The generated project will be automatically
     upgraded to VS2012 format by the IDE.

Tests:

     I built X64 and X86 VMs inside VS2012 and ran Eclipse.
     JPRT

Thanks
- Ioi


From kamggg at gmail.com  Mon Aug 26 18:47:42 2013
From: kamggg at gmail.com (Keith McGuigan)
Date: Mon, 26 Aug 2013 21:47:42 -0400
Subject: RFR (XXS) 8020622 - Visual Studio 2012 project creation for
	hotspot
In-Reply-To: <521BFE36.2020708@oracle.com>
References: <521BFE36.2020708@oracle.com>
Message-ID: <CAFUO74k+gO5ir16HXhHVBbGgXFOoYQG1A1rUFv38i9Z1S4fukw@mail.gmail.com>

Looks ok to me (kamg)


On Mon, Aug 26, 2013 at 9:17 PM, Ioi Lam <ioi.lam at oracle.com> wrote:

> Please review a very small fix:
>
> http://cr.openjdk.java.net/~**iklam/8020622/vs2012_proj_001/<http://cr.openjdk.java.net/~iklam/8020622/vs2012_proj_001/>
>
> Bug: create.bat on Windows failed to create project file for Visual Studio
> 2012
>
>     https://bugs.openjdk.java.net/**browse/JDK-8020622<https://bugs.openjdk.java.net/browse/JDK-8020622>
>
> Summary of fix:
>
>     Treat VS2012 as VS2010. The generated project will be automatically
>     upgraded to VS2012 format by the IDE.
>
> Tests:
>
>     I built X64 and X86 VMs inside VS2012 and ran Eclipse.
>     JPRT
>
> Thanks
> - Ioi
>
>


-- 
- Keith McGuigan <keith.mcguigan at alumni.unh.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130826/caced771/attachment.html 

From daniel.daugherty at oracle.com  Mon Aug 26 19:00:03 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 26 Aug 2013 20:00:03 -0600
Subject: RFR (XXS) 8020622 - Visual Studio 2012 project creation for
	hotspot
In-Reply-To: <521BFE36.2020708@oracle.com>
References: <521BFE36.2020708@oracle.com>
Message-ID: <521C0823.6070408@oracle.com>

On 8/26/13 7:17 PM, Ioi Lam wrote:
> Please review a very small fix:
>
> http://cr.openjdk.java.net/~iklam/8020622/vs2012_proj_001/

make/windows/create.bat
     No comments.

make/windows/makefiles/rules.make
     line 74: # upgrade them automatically yo VS2012 format).
         typo: 'yo' -> 'to'

Thumbs up.

Dan


>
> Bug: create.bat on Windows failed to create project file for Visual 
> Studio 2012
>
>     https://bugs.openjdk.java.net/browse/JDK-8020622
>
> Summary of fix:
>
>     Treat VS2012 as VS2010. The generated project will be automatically
>     upgraded to VS2012 format by the IDE.
>
> Tests:
>
>     I built X64 and X86 VMs inside VS2012 and ran Eclipse.
>     JPRT
>
> Thanks
> - Ioi
>


From david.holmes at oracle.com  Mon Aug 26 19:41:25 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 27 Aug 2013 12:41:25 +1000
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521BA02E.6080901@oracle.com>
References: <521BA02E.6080901@oracle.com>
Message-ID: <521C11D5.1000409@oracle.com>

On 27/08/2013 4:36 AM, Lois Foltan wrote:
> Please review the following fix:
>
> Internal webrev:
>
> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>
> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>           runtime/6878713/Test6878713.sh fails on mac
>
>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
> https://bugs.openjdk.java.net/browse/JDK-8022140
>
> Summary of fix:
>      On MacOS, currently Hotspot is built specifying the -fcheck-new
> command line option to the llvm-g++ compiler.
>      The -fcheck-new option directs the compiler to "check that the
> pointer returned by |operator new| is non-null
>       before attempting to modify the storage allocated."  The clang++
> compiler does not support the
>       -fcheck-new option.  To obtain similiar functionality when
> building Hotspot with clang++, empty exception
>       throw() specifications must be added to all user-defined operator
> new()'s.

We just spotted something related in the PPC64 port and were going the 
other way or removing these "spurious" throw() declarations.

But this seems really ugly - is there really a need to specialize this 
for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers 
honour the nothrow() semantics?

That said I thought we already handled this using the "const 
std::nothrow_t&  nothrow_constant" where needed? Our other operator new 
implementations shouldn't return NULL but will abort.

So why do we need -fcheck-new or this empty throw() ?

Thanks,
David

> Tests:
>
>       Solaris: built fastdebug & product images
>       Linux: built fastdebug & product images
>       MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>                      built fastdebug & product images using clang++ -
> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>       Windows:  built fastdebug & product images with VS2010
>

From david.holmes at oracle.com  Mon Aug 26 20:50:14 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 27 Aug 2013 13:50:14 +1000
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <521B5B0B.30709@oracle.com>
References: <52174654.8020400@oracle.com> <5217C296.7070807@oracle.com>
	<521B544E.6090201@oracle.com> <521B5A65.40701@oracle.com>
	<521B5B0B.30709@oracle.com>
Message-ID: <521C21F6.90003@oracle.com>

On 26/08/2013 11:41 PM, Daniel D. Daugherty wrote:
> So when we're trying to test with -Xcomp we actually don't?
> That sounds rather wrong to me.

This is a general problem we are facing with tests that launch other 
VMs. The initial test gets invoked with a bunch of flags from the 
current "test configuration" but these don't get passed through to the 
launched VM. There is a bug open for this:

8019502 The tests which launch Java from code should be modified to 
launch Java with options used to run the testing Java

but it isn't a black and white situation. Sometimes, like with your 
debuggeeVMoptions, you don't want the same flags.

Of course when we do want it we need a mechanism to allow it. The shell 
scripts could access env variables set by jtreg. I think Java code can 
access system properties with the same info. This then needs to be 
passed through to the Processtools.

Just as an aside: note also that jtreg doesn't know when 
-javaoptions/-vmoptions is passing a VM selection flag (-client, 
-server, -minimal) or mode flag (Xcomp, Xint, Xmixed) and so the version 
info in the jtr file is often wrong.

Cheers,
David

> Dan
>
>
> On 8/26/13 7:38 AM, Leonid Mesnik wrote:
>> Dan
>>
>> ProcessTools.createJavaProcessBuilder don't use test java options. So
>> all java invocations are always in '-Xmixed'.
>>
>> Leonid
>>
>> On 08/26/2013 05:12 PM, Aleksey Shipilev wrote:
>>> Hi Dan,
>>>
>>> On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
>>>> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>>>> Here's the webrev:
>>>>>     http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>>>> hotspot/test/runtime/contended/Options.java
>>>>      I count 11 Java process invocations. Will the default timeout
>>>>      of 120 seconds be enough for a fastdebug '-server -Xcomp'
>>>>      run on something like Solaris SPARC.
>>> Linux i5/x86_64 laptop passes this test in 5 seconds. I think there is
>>> enough headroom for slower machines.
>>>
>>>>      The fragments:
>>>>
>>>>          "must be the between"
>>>>          "must be the multiple of 8"
>>>>
>>>>      probably match the real error messages, but those messages
>>>>      aren't quite proper English. I expected:
>>>>
>>>>          "must be in between"
>>>>          "must be a multiple of 8"
>>> Yes. Unfortunately, this is what VM outputs. Does it make sense to fix
>>> the error messages in VM along with the regression test? If so, here is
>>> the new webrev:
>>>    http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>>>
>>> -Aleksey.
>>
>>
>

From yumin.qi at oracle.com  Mon Aug 26 21:55:34 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 26 Aug 2013 21:55:34 -0700
Subject: RFR (XXS) 8020622 - Visual Studio 2012 project creation for
	hotspot
In-Reply-To: <521BFE36.2020708@oracle.com>
References: <521BFE36.2020708@oracle.com>
Message-ID: <521C3146.8000706@oracle.com>

Looks good to me.

Thanks
Yumin

On 8/26/2013 6:17 PM, Ioi Lam wrote:
> Please review a very small fix:
>
> http://cr.openjdk.java.net/~iklam/8020622/vs2012_proj_001/
>
> Bug: create.bat on Windows failed to create project file for Visual 
> Studio 2012
>
>     https://bugs.openjdk.java.net/browse/JDK-8020622
>
> Summary of fix:
>
>     Treat VS2012 as VS2010. The generated project will be automatically
>     upgraded to VS2012 format by the IDE.
>
> Tests:
>
>     I built X64 and X86 VMs inside VS2012 and ran Eclipse.
>     JPRT
>
> Thanks
> - Ioi
>


From daniel.daugherty at oracle.com  Tue Aug 27 00:32:31 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Tue, 27 Aug 2013 07:32:31 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130827073239.25E8548BAD@hg.openjdk.java.net>

Changeset: 4a1efab850f4
Author:    shade
Date:      2013-08-26 17:42 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4a1efab850f4

8023638: Add the regression test for 8006997
Summary: Add the relevant test and proofread the VM messages as well
Reviewed-by: coleenp, mseledtsov, dcubed

! src/share/vm/runtime/arguments.cpp
+ test/runtime/contended/Options.java

Changeset: a7d8baf4cca7
Author:    dcubed
Date:      2013-08-26 18:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a7d8baf4cca7

Merge



From bengt.rutisson at oracle.com  Tue Aug 27 01:01:12 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 27 Aug 2013 10:01:12 +0200
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521B89F4.6010403@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com>
Message-ID: <521C5CC8.5060102@oracle.com>


Yumin,

On 8/26/13 7:01 PM, Yumin Qi wrote:
> Bengt,
>
>   Thanks for your comments.
>   Yes, as you said, the purpose of rotating logs is primarily targeted 
> for saving disk space. This bug is supplying  customers another option 
> to prevent the previous gc logs from removed by restart app without 
> making copy. Now with this pid and time stamp included in file name,  
> we have more options for users. It is up to user to make decision to 
> or not to keep the logs. We cannot handle all the requests in JVM, but 
> we can offer the choices for users I think. Any way, with either the 
> previous rotating version, or the one I am working, the logs will not 
> grow constantly without limit to blow storage out as long as users 
> give enough attention.
>
>   My concern is for no log rotation, should we still use time stamp in 
> file name? I have one version for this, I hope get more comments for 
> that.

Sorry if I wasn't clear before. I am not worried about the case when log 
rotation is turned on. What I was worried about was the case where a 
user is not using log rotation but is still piping the GC output to a 
file. That file will be overwritten every time the VM is restarted. If 
we add time stamps to the file name for this case then the file will not 
be overwritten. I think that is a bit of a scary change. That's all.

Bengt

>
>   More comments are appreciated by sending to more wide audience, 
> especially sustaining, they have more experience with customer request.
>
> Thanks
> Yumin
>
>
>
> On 8/26/2013 4:47 AM, Bengt Rutisson wrote:
>>
>> Hi Yumin and Tao,
>>
>> I have not reviewed the code change but I have a comment inlined below.
>>
>> On 8/24/13 1:05 AM, Yumin Qi wrote:
>>> Tao,
>>>
>>>   Thanks for your review.
>>>
>>> On 8/23/2013 3:33 PM, Tao Mao wrote:
>>>> Hi,
>>>>
>>>> I reviewed most of the code and test-ran a build from it. It's a 
>>>> very cool and important improvement.
>>>>
>>>> Thank you for putting together these on our wishlist for long.
>>>>
>>>> Below are some comments.
>>>>
>>>> 1. src/share/vm/runtime/arguments.cpp
>>>>
>>>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>>>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>>>
>>>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>>>
>>>> I worked on a problem of enabling gc log limit over 2G 
>>>> (JDK-7122222). So it seems that customers sometimes want gc logs to 
>>>> be very large.
>>>>
>>> Sure, will add.
>>>> 2. src/share/vm/runtime/arguments.hpp
>>>>
>>>> (1) with the current changeset, we only append date&time to 
>>>> file_name w/ +UseGCLogFileRotation; if not, we won't have date&time 
>>>> info.
>>>>
>>>> I think it would be useful to let both cases (w/ and w/o 
>>>> UseGCLogFileRotation) have date&time in order to solve the 
>>>> overwritten problem (e.g. JDK-8020667). In fact, having that, we 
>>>> actually solve JDK-8020667.
>>>>
>>>> If you want to have that, basically you need to work on the 
>>>> FileStream constructor methods fileStream().
>>>>
>>> I can change that, if no objection from others. This also will 
>>> simplify the setting of file name here.
>>
>> I think appending a timestamp to the log file name is a nice idea, 
>> but I think it is also a bit scary. There are users who restart their 
>> applications regularly. With the suggested idea such users will now 
>> risk filling up their disk space with log files. I imagine that that 
>> will not be appreciated by everyone. Such a change should probably be 
>> discussed more thoroughly than just in a review request.
>>
>> Thanks,
>> Bengt
>>
>>
>>>
>>>> (2) Would it be better to rename method name reformat_filename() to 
>>>> extend_filename()?
>>>>
>>>> (3) Typos and suggestion
>>>> 537 // rotate file in names filename.0, filename.1, ..., 
>>>> filename.<NumberOfGCLogFiles - 1>
>>>> *=> extended_filename.0*
>>>>
>>>> 538 // filename contains pid and time when the fist file created. 
>>>> The current filename is
>>>> *=> *the*first *file created.
>>>>
>>>> 539 // gc_log_file_name + pid<pid> + 
>>>> YYYY-MM-DD_HH-MM-SS.<i>.current, where i is current
>>>> 540 // rotation file number. After it reaches max file size, the 
>>>> file will be saved and
>>>> 541 // renamed with .current removed from its tail.
>>>>
>>> Will change that.
>>>> 3. For your point 5), I don't quite get it. In my test-run, I tried 
>>>> to change file permission to unreadable and unwritable, but VM 
>>>> would later change the permission back anyway.
>>>>
>>>> So could you bring up some use cases of that functionality to give 
>>>> more details?
>>>>
>>> Changing file permission will not stop the file create, in this 
>>> rotation, the file opened/saved/removed/renamed -> then repeat. What 
>>> I have done is change the while directory to read only, then the 
>>> create failed so rotation stopped.
>>>
>>>> 4. Will you write jtreg tests for this functionality? It looks 
>>>> possible to write some tests, at least checking the format of log 
>>>> names.
>>>>
>>> Good suggestion, I will add one.
>>>
>>>> Thanks.
>>>> Tao
>>>>
>>>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>>>> Could I get  a GC staff review the change? Need more reviewers to 
>>>>> push this in.
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>>>> Hi, all
>>>>>>
>>>>>>   This is second version after feedback from first round.
>>>>>>   The changes are:
>>>>>>
>>>>>>   1) file name will be based on gc log file name 
>>>>>> (-Xloggc:filename), pid (process id) and time when the first 
>>>>>> rotation file created:
>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>>>   2) If rotate in same file, file name is as in 1), if rotate in 
>>>>>> multiple files, .<i> will append to above file name.
>>>>>>   3) every time file rotated, file name and time when file 
>>>>>> created will be logged to head/tail, this is same as first version.
>>>>>>   4) current file has name 
>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>>>        This is similar to first version.
>>>>>>        By adapting such name format we will never loss logs in 
>>>>>> case apps stops and restart, the log files will not be 
>>>>>> overwritten since time stamp in file names.
>>>>>>    5) If open file failed, turn off gc log rotation.
>>>>>>         If due to some reason, file operation failed (such as 
>>>>>> permission changed etc), with log file opened, logging still 
>>>>>> works, but at
>>>>>>         saving and renaming, the file operation will fail, this 
>>>>>> will lead not all files saved.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>>>
>>>>>>      Tested with jtreg, JPRT.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>   Can I have your review for this small changes?
>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>>>
>>>>>>>    This is for a enhancement to add head/tail message to the 
>>>>>>> logging files to assist reading GC output.
>>>>>>>    1. modified prompt message if invalid arguments used for log 
>>>>>>> rotating;
>>>>>>>    2. add time and file name message to log file head/tail.
>>>>>>>    3. for easily identify which log file is current, use file 
>>>>>>> name like <filename>.n.current, after it reaches maximum size, 
>>>>>>> rename it to <filename>.n
>>>>>>>         On Windows, there is no F_OK (existing test) definition, 
>>>>>>> F_OK is defined as "0" and for _access of VC++, it just describes:
>>>>>>>
>>>>>>> modevalue
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Checks file for
>>>>>>>
>>>>>>> 00
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Existence only
>>>>>>>
>>>>>>> 02
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Write-only
>>>>>>>
>>>>>>> 04
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Read-only
>>>>>>>
>>>>>>> 06
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Read and write
>>>>>>>
>>>>>>>
>>>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>>>> The definition are consistent with unistd.h.
>>>>>>>
>>>>>>>     Test: JPRT and jtreg.
>>>>>>>
>>>>>>>    Thanks
>>>>>>>    Yumin
>>>>>>
>>>>>
>>>
>>>
>>
>


From mikael.gerdin at oracle.com  Tue Aug 27 01:01:48 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 27 Aug 2013 10:01:48 +0200
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521C11D5.1000409@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
Message-ID: <521C5CEC.90507@oracle.com>



On 2013-08-27 04:41, David Holmes wrote:
> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>> Please review the following fix:
>>
>> Internal webrev:
>>
>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>
>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>           runtime/6878713/Test6878713.sh fails on mac
>>
>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>
>> Summary of fix:
>>      On MacOS, currently Hotspot is built specifying the -fcheck-new
>> command line option to the llvm-g++ compiler.
>>      The -fcheck-new option directs the compiler to "check that the
>> pointer returned by |operator new| is non-null
>>       before attempting to modify the storage allocated."  The clang++
>> compiler does not support the
>>       -fcheck-new option.  To obtain similiar functionality when
>> building Hotspot with clang++, empty exception
>>       throw() specifications must be added to all user-defined operator
>> new()'s.
>
> We just spotted something related in the PPC64 port and were going the
> other way or removing these "spurious" throw() declarations.
>
> But this seems really ugly - is there really a need to specialize this
> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
> honour the nothrow() semantics?
>
> That said I thought we already handled this using the "const
> std::nothrow_t&  nothrow_constant" where needed? Our other operator new
> implementations shouldn't return NULL but will abort.
>
> So why do we need -fcheck-new or this empty throw() ?

I guess that if the C++ compiler knows that operator new() will throw an 
exception if an allocation fails then it doesn't need to emit code to 
explicitly avoid calling the constructor.

If we declare operator new() with an empty throw() we will also inform 
the compiler that new can't throw an exception and therefore the 
compiler needs to explicitly handle failed allocations.

The g++ man page states:

        -fcheck-new
            Check that the pointer returned by "operator new" is 
non-null before attempting to modify the storage allocated.  This check 
is normally unnecessary because the C++ standard specifies that
            "operator new" will only return 0 if it is declared throw(), 
in which case the compiler will always check the return value even 
without this option.  In all other cases, when "operator new"
            has a non-empty exception specification, memory exhaustion 
is signalled by throwing "std::bad_alloc".  See also new (nothrow).

/Mikael

>
> Thanks,
> David
>
>> Tests:
>>
>>       Solaris: built fastdebug & product images
>>       Linux: built fastdebug & product images
>>       MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>                      built fastdebug & product images using clang++ -
>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>       Windows:  built fastdebug & product images with VS2010
>>

From kirk at kodewerk.com  Tue Aug 27 01:13:42 2013
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Tue, 27 Aug 2013 10:13:42 +0200
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521C5CC8.5060102@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>
Message-ID: <51B514BC-98EE-4CD8-A664-9579AC766391@kodewerk.com>


On 2013-08-27, at 10:01 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:

> 
> Yumin,
> 
> On 8/26/13 7:01 PM, Yumin Qi wrote:
>> Bengt,
>> 
>>  Thanks for your comments.
>>  Yes, as you said, the purpose of rotating logs is primarily targeted for saving disk space. This bug is supplying  customers another option to prevent the previous gc logs from removed by restart app without making copy. Now with this pid and time stamp included in file name,  we have more options for users. It is up to user to make decision to or not to keep the logs. We cannot handle all the requests in JVM, but we can offer the choices for users I think. Any way, with either the previous rotating version, or the one I am working, the logs will not grow constantly without limit to blow storage out as long as users give enough attention.
>> 
>>  My concern is for no log rotation, should we still use time stamp in file name? I have one version for this, I hope get more comments for that.
> 
> Sorry if I wasn't clear before. I am not worried about the case when log rotation is turned on. What I was worried about was the case where a user is not using log rotation but is still piping the GC output to a file. That file will be overwritten every time the VM is restarted. If we add time stamps to the file name for this case then the file will not be overwritten. I think that is a bit of a scary change. That's all.

This falls into the category of unexpected behaviour and I would agree that unless log rotation has been specified I would not like to see the name changed.. even though I'll admit to be bitten by having a log file "accidentally" over written. That said, it would be excellent if the new %<x> macros (where it makes sense of course) could be applied to the -Xloggc flag even when rotation is not turned on.

Regards,
Kirk


From staffan.larsen at oracle.com  Tue Aug 27 01:41:17 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 27 Aug 2013 10:41:17 +0200
Subject: RFR: 8023720: setjmp/longjmp changes the process signal mask on OS X 
Message-ID: <3F44268B-E81C-421C-BD52-6395876D7652@oracle.com>

The original conversation about this problem is here:  http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html 

In short, setjmp/longjmp on OS X messes up the signal mask and we should use _setjmp/_longjmp instead.

This change fixes two occurences in the jdk. There are a couple more in the client and hotspot areas which I will file followup bugs about.

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

Thanks,
/Staffan

From staffan.larsen at oracle.com  Tue Aug 27 01:48:53 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 27 Aug 2013 10:48:53 +0200
Subject: RFR: 8023720: setjmp/longjmp changes the process signal mask on
	OS X 
In-Reply-To: <3F44268B-E81C-421C-BD52-6395876D7652@oracle.com>
References: <3F44268B-E81C-421C-BD52-6395876D7652@oracle.com>
Message-ID: <C0C4F10B-7450-4DA6-9428-7D9434186EEC@oracle.com>

I have also made a fix for hotspot. I messed up the link in the last email so here are both webrevs.
 
jdk: http://cr.openjdk.java.net/~sla/8023786/webrev.00/
hotspot: http://cr.openjdk.java.net/~sla/8023720/webrev.00/

Thanks,
/Staffan

On 27 aug 2013, at 10:41, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> The original conversation about this problem is here:  http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html 
> 
> In short, setjmp/longjmp on OS X messes up the signal mask and we should use _setjmp/_longjmp instead.
> 
> This change fixes two occurences in the jdk. There are a couple more in the client and hotspot areas which I will file followup bugs about.
> 
> webrev: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
> 
> Thanks,
> /Staffan


From david.holmes at oracle.com  Tue Aug 27 04:31:41 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 27 Aug 2013 21:31:41 +1000
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521C5CEC.90507@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com>
Message-ID: <521C8E1D.5030802@oracle.com>

On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
> On 2013-08-27 04:41, David Holmes wrote:
>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>> Please review the following fix:
>>>
>>> Internal webrev:
>>>
>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>
>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>>           runtime/6878713/Test6878713.sh fails on mac
>>>
>>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>
>>> Summary of fix:
>>>      On MacOS, currently Hotspot is built specifying the -fcheck-new
>>> command line option to the llvm-g++ compiler.
>>>      The -fcheck-new option directs the compiler to "check that the
>>> pointer returned by |operator new| is non-null
>>>       before attempting to modify the storage allocated."  The clang++
>>> compiler does not support the
>>>       -fcheck-new option.  To obtain similiar functionality when
>>> building Hotspot with clang++, empty exception
>>>       throw() specifications must be added to all user-defined operator
>>> new()'s.
>>
>> We just spotted something related in the PPC64 port and were going the
>> other way or removing these "spurious" throw() declarations.
>>
>> But this seems really ugly - is there really a need to specialize this
>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
>> honour the nothrow() semantics?
>>
>> That said I thought we already handled this using the "const
>> std::nothrow_t&  nothrow_constant" where needed? Our other operator new
>> implementations shouldn't return NULL but will abort.
>>
>> So why do we need -fcheck-new or this empty throw() ?
>
> I guess that if the C++ compiler knows that operator new() will throw an
> exception if an allocation fails then it doesn't need to emit code to
> explicitly avoid calling the constructor.

Yes that is what happens, but why do _we_ need it when ...

> If we declare operator new() with an empty throw() we will also inform
> the compiler that new can't throw an exception and therefore the
> compiler needs to explicitly handle failed allocations.

... we have two kinds of operator new implementations (or at least we 
_should_ only have two kinds):

1. Will abort on OOM (either ResourceArea exhaustion or Stack 
exhaustion) and so never returns NULL
2. Can return NULL and uses std::nothrow to indicate that

So we should not need this if the nothrow is acting as I think it 
should. Have we missed places where nothrow is needed? Do we have errant 
operator new definitions unrelated to the allocation base classes?

David
-----

> The g++ man page states:
>
>         -fcheck-new
>             Check that the pointer returned by "operator new" is
> non-null before attempting to modify the storage allocated.  This check
> is normally unnecessary because the C++ standard specifies that
>             "operator new" will only return 0 if it is declared throw(),
> in which case the compiler will always check the return value even
> without this option.  In all other cases, when "operator new"
>             has a non-empty exception specification, memory exhaustion
> is signalled by throwing "std::bad_alloc".  See also new (nothrow).
>
> /Mikael
>
>>
>> Thanks,
>> David
>>
>>> Tests:
>>>
>>>       Solaris: built fastdebug & product images
>>>       Linux: built fastdebug & product images
>>>       MacOS:  built fastdebug & product images using llvm-g++ - ran
>>> JTREG
>>>                      built fastdebug & product images using clang++ -
>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>       Windows:  built fastdebug & product images with VS2010
>>>

From david.holmes at oracle.com  Tue Aug 27 04:38:40 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 27 Aug 2013 21:38:40 +1000
Subject: RFR: 8023720: setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <C0C4F10B-7450-4DA6-9428-7D9434186EEC@oracle.com>
References: <3F44268B-E81C-421C-BD52-6395876D7652@oracle.com>
	<C0C4F10B-7450-4DA6-9428-7D9434186EEC@oracle.com>
Message-ID: <521C8FC0.4010004@oracle.com>

On 27/08/2013 6:48 PM, Staffan Larsen wrote:
> I have also made a fix for hotspot. I messed up the link in the last email so here are both webrevs.
>
> jdk: http://cr.openjdk.java.net/~sla/8023786/webrev.00/

Seems okay.

> hotspot: http://cr.openjdk.java.net/~sla/8023720/webrev.00/

??? You didn't use _setjmp/_longjmp you just tried to save and restore 
the current thread's sigmask. Which won't help in general if longjmp 
just fubar'd the process sigmask. The effect of setting the process 
sigmask in a multi-threaded process is undefined.

David


> Thanks,
> /Staffan
>
> On 27 aug 2013, at 10:41, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>
>> The original conversation about this problem is here:  http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html
>>
>> In short, setjmp/longjmp on OS X messes up the signal mask and we should use _setjmp/_longjmp instead.
>>
>> This change fixes two occurences in the jdk. There are a couple more in the client and hotspot areas which I will file followup bugs about.
>>
>> webrev: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>>
>> Thanks,
>> /Staffan
>

From staffan.larsen at oracle.com  Tue Aug 27 04:41:40 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 27 Aug 2013 13:41:40 +0200
Subject: RFR: 8023720: setjmp/longjmp changes the process signal mask on
	OS X
In-Reply-To: <521C8FC0.4010004@oracle.com>
References: <3F44268B-E81C-421C-BD52-6395876D7652@oracle.com>
	<C0C4F10B-7450-4DA6-9428-7D9434186EEC@oracle.com>
	<521C8FC0.4010004@oracle.com>
Message-ID: <BE98F433-6913-4107-96D0-B0CA6F3439E7@oracle.com>


On 27 aug 2013, at 13:38, David Holmes <David.Holmes at oracle.com> wrote:

> On 27/08/2013 6:48 PM, Staffan Larsen wrote:
>> I have also made a fix for hotspot. I messed up the link in the last email so here are both webrevs.
>> 
>> jdk: http://cr.openjdk.java.net/~sla/8023786/webrev.00/
> 
> Seems okay.
> 
>> hotspot: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
> 
> ??? You didn't use _setjmp/_longjmp you just tried to save and restore the current thread's sigmask. Which won't help in general if longjmp just fubar'd the process sigmask. The effect of setting the process sigmask in a multi-threaded process is undefined.

Ah, but in this case we use sigsetjmp/siglongjmp which do not touch the signal mask if sigsetjmp is called with 0 as the second parameter. 

/Staffan

> 
> David
> 
> 
>> Thanks,
>> /Staffan
>> 
>> On 27 aug 2013, at 10:41, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>> 
>>> The original conversation about this problem is here:  http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html
>>> 
>>> In short, setjmp/longjmp on OS X messes up the signal mask and we should use _setjmp/_longjmp instead.
>>> 
>>> This change fixes two occurences in the jdk. There are a couple more in the client and hotspot areas which I will file followup bugs about.
>>> 
>>> webrev: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>>> 
>>> Thanks,
>>> /Staffan
>> 


From david.holmes at oracle.com  Tue Aug 27 04:45:59 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 27 Aug 2013 21:45:59 +1000
Subject: RFR: 8023720: setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <BE98F433-6913-4107-96D0-B0CA6F3439E7@oracle.com>
References: <3F44268B-E81C-421C-BD52-6395876D7652@oracle.com>
	<C0C4F10B-7450-4DA6-9428-7D9434186EEC@oracle.com>
	<521C8FC0.4010004@oracle.com>
	<BE98F433-6913-4107-96D0-B0CA6F3439E7@oracle.com>
Message-ID: <521C9177.6030907@oracle.com>

On 27/08/2013 9:41 PM, Staffan Larsen wrote:
>
> On 27 aug 2013, at 13:38, David Holmes <David.Holmes at oracle.com> wrote:
>
>> On 27/08/2013 6:48 PM, Staffan Larsen wrote:
>>> I have also made a fix for hotspot. I messed up the link in the last email so here are both webrevs.
>>>
>>> jdk: http://cr.openjdk.java.net/~sla/8023786/webrev.00/
>>
>> Seems okay.
>>
>>> hotspot: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>>
>> ??? You didn't use _setjmp/_longjmp you just tried to save and restore the current thread's sigmask. Which won't help in general if longjmp just fubar'd the process sigmask. The effect of setting the process sigmask in a multi-threaded process is undefined.
>
> Ah, but in this case we use sigsetjmp/siglongjmp which do not touch the signal mask if sigsetjmp is called with 0 as the second parameter.

Ah! Sorry it's getting late and I missed the sig part. Makes sense now.

Reviewed.

Thanks,
David

> /Staffan
>
>>
>> David
>>
>>
>>> Thanks,
>>> /Staffan
>>>
>>> On 27 aug 2013, at 10:41, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>
>>>> The original conversation about this problem is here:  http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html
>>>>
>>>> In short, setjmp/longjmp on OS X messes up the signal mask and we should use _setjmp/_longjmp instead.
>>>>
>>>> This change fixes two occurences in the jdk. There are a couple more in the client and hotspot areas which I will file followup bugs about.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>>>>
>>>> Thanks,
>>>> /Staffan
>>>
>

From karen.kinnear at oracle.com  Tue Aug 27 04:50:32 2013
From: karen.kinnear at oracle.com (karen.kinnear at oracle.com)
Date: Tue, 27 Aug 2013 11:50:32 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130827115038.3E34748BBE@hg.openjdk.java.net>

Changeset: 91b93f523ec6
Author:    acorn
Date:      2013-08-26 11:35 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/91b93f523ec6

8012294: remove generic handling for default methods
Reviewed-by: kamg, coleenp

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/defaultMethods.cpp
- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp
! src/share/vm/runtime/globals.hpp

Changeset: d80493ee6430
Author:    acorn
Date:      2013-08-27 01:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d80493ee6430

Merge

- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp
! src/share/vm/runtime/globals.hpp


From staffan.larsen at oracle.com  Tue Aug 27 04:54:46 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 27 Aug 2013 13:54:46 +0200
Subject: RFR: 8023720: setjmp/longjmp changes the process signal mask on
	OS X
In-Reply-To: <521C9177.6030907@oracle.com>
References: <3F44268B-E81C-421C-BD52-6395876D7652@oracle.com>
	<C0C4F10B-7450-4DA6-9428-7D9434186EEC@oracle.com>
	<521C8FC0.4010004@oracle.com>
	<BE98F433-6913-4107-96D0-B0CA6F3439E7@oracle.com>
	<521C9177.6030907@oracle.com>
Message-ID: <8DC1C503-416D-4CF4-AD3B-DB8B51EAF694@oracle.com>

Thanks!

On 27 aug 2013, at 13:45, David Holmes <David.Holmes at oracle.com> wrote:

> On 27/08/2013 9:41 PM, Staffan Larsen wrote:
>> 
>> On 27 aug 2013, at 13:38, David Holmes <David.Holmes at oracle.com> wrote:
>> 
>>> On 27/08/2013 6:48 PM, Staffan Larsen wrote:
>>>> I have also made a fix for hotspot. I messed up the link in the last email so here are both webrevs.
>>>> 
>>>> jdk: http://cr.openjdk.java.net/~sla/8023786/webrev.00/
>>> 
>>> Seems okay.
>>> 
>>>> hotspot: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>>> 
>>> ??? You didn't use _setjmp/_longjmp you just tried to save and restore the current thread's sigmask. Which won't help in general if longjmp just fubar'd the process sigmask. The effect of setting the process sigmask in a multi-threaded process is undefined.
>> 
>> Ah, but in this case we use sigsetjmp/siglongjmp which do not touch the signal mask if sigsetjmp is called with 0 as the second parameter.
> 
> Ah! Sorry it's getting late and I missed the sig part. Makes sense now.
> 
> Reviewed.
> 
> Thanks,
> David
> 
>> /Staffan
>> 
>>> 
>>> David
>>> 
>>> 
>>>> Thanks,
>>>> /Staffan
>>>> 
>>>> On 27 aug 2013, at 10:41, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>> 
>>>>> The original conversation about this problem is here:  http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html
>>>>> 
>>>>> In short, setjmp/longjmp on OS X messes up the signal mask and we should use _setjmp/_longjmp instead.
>>>>> 
>>>>> This change fixes two occurences in the jdk. There are a couple more in the client and hotspot areas which I will file followup bugs about.
>>>>> 
>>>>> webrev: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>>>>> 
>>>>> Thanks,
>>>>> /Staffan
>>>> 
>> 


From leonid.mesnik at oracle.com  Tue Aug 27 05:05:54 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Tue, 27 Aug 2013 16:05:54 +0400
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <521C21F6.90003@oracle.com>
References: <52174654.8020400@oracle.com> <5217C296.7070807@oracle.com>
	<521B544E.6090201@oracle.com> <521B5A65.40701@oracle.com>
	<521B5B0B.30709@oracle.com> <521C21F6.90003@oracle.com>
Message-ID: <521C9622.8060403@oracle.com>

We should update ProcessTools so it add 
'System.getProperty("test.java.opts")'  to test java options.

Also some of combinations are invalid and test should silently pass 
(skip) in such case.
For example tests on CMS should just pass when we test any other GC and 
specify this as -javaoption.


Leonid

On 08/27/2013 07:50 AM, David Holmes wrote:
> On 26/08/2013 11:41 PM, Daniel D. Daugherty wrote:
>> So when we're trying to test with -Xcomp we actually don't?
>> That sounds rather wrong to me.
>
> This is a general problem we are facing with tests that launch other 
> VMs. The initial test gets invoked with a bunch of flags from the 
> current "test configuration" but these don't get passed through to the 
> launched VM. There is a bug open for this:
>
> 8019502 The tests which launch Java from code should be modified to 
> launch Java with options used to run the testing Java
>
> but it isn't a black and white situation. Sometimes, like with your 
> debuggeeVMoptions, you don't want the same flags.
>
> Of course when we do want it we need a mechanism to allow it. The 
> shell scripts could access env variables set by jtreg. I think Java 
> code can access system properties with the same info. This then needs 
> to be passed through to the Processtools.
>
> Just as an aside: note also that jtreg doesn't know when 
> -javaoptions/-vmoptions is passing a VM selection flag (-client, 
> -server, -minimal) or mode flag (Xcomp, Xint, Xmixed) and so the 
> version info in the jtr file is often wrong.
>
> Cheers,
> David
>
>> Dan
>>
>>
>> On 8/26/13 7:38 AM, Leonid Mesnik wrote:
>>> Dan
>>>
>>> ProcessTools.createJavaProcessBuilder don't use test java options. So
>>> all java invocations are always in '-Xmixed'.
>>>
>>> Leonid
>>>
>>> On 08/26/2013 05:12 PM, Aleksey Shipilev wrote:
>>>> Hi Dan,
>>>>
>>>> On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
>>>>> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>>>>> Here's the webrev:
>>>>>>     http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>>>>> hotspot/test/runtime/contended/Options.java
>>>>>      I count 11 Java process invocations. Will the default timeout
>>>>>      of 120 seconds be enough for a fastdebug '-server -Xcomp'
>>>>>      run on something like Solaris SPARC.
>>>> Linux i5/x86_64 laptop passes this test in 5 seconds. I think there is
>>>> enough headroom for slower machines.
>>>>
>>>>>      The fragments:
>>>>>
>>>>>          "must be the between"
>>>>>          "must be the multiple of 8"
>>>>>
>>>>>      probably match the real error messages, but those messages
>>>>>      aren't quite proper English. I expected:
>>>>>
>>>>>          "must be in between"
>>>>>          "must be a multiple of 8"
>>>> Yes. Unfortunately, this is what VM outputs. Does it make sense to fix
>>>> the error messages in VM along with the regression test? If so, 
>>>> here is
>>>> the new webrev:
>>>>    http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>>>>
>>>> -Aleksey.
>>>
>>>
>>


-- 
Leonid Mesnik
JVM SQE


From christian.tornqvist at oracle.com  Tue Aug 27 05:29:15 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Tue, 27 Aug 2013 14:29:15 +0200
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <521C9622.8060403@oracle.com>
References: <52174654.8020400@oracle.com>
	<5217C296.7070807@oracle.com>	<521B544E.6090201@oracle.com>
	<521B5A65.40701@oracle.com>	<521B5B0B.30709@oracle.com>
	<521C21F6.90003@oracle.com> <521C9622.8060403@oracle.com>
Message-ID: <008201cea321$0c337430$249a5c90$@oracle.com>

No, we should not update ProcessTools with this, many of the tests that use
ProcessTools need explicit control over the command line. The ones that
should pass on javaopts should add the test.java.opts themselves to the
arguments passed to the child process.

/ Christian

-----Original Message-----
From: hotspot-runtime-dev-bounces at openjdk.java.net
[mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Leonid
Mesnik
Sent: Tuesday, August 27, 2013 2:06 PM
To: David Holmes
Cc: hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR (S) CR 8023638: Add the regression test for 8006997

We should update ProcessTools so it add
'System.getProperty("test.java.opts")'  to test java options.

Also some of combinations are invalid and test should silently pass
(skip) in such case.
For example tests on CMS should just pass when we test any other GC and
specify this as -javaoption.


Leonid

On 08/27/2013 07:50 AM, David Holmes wrote:
> On 26/08/2013 11:41 PM, Daniel D. Daugherty wrote:
>> So when we're trying to test with -Xcomp we actually don't?
>> That sounds rather wrong to me.
>
> This is a general problem we are facing with tests that launch other 
> VMs. The initial test gets invoked with a bunch of flags from the 
> current "test configuration" but these don't get passed through to the 
> launched VM. There is a bug open for this:
>
> 8019502 The tests which launch Java from code should be modified to 
> launch Java with options used to run the testing Java
>
> but it isn't a black and white situation. Sometimes, like with your 
> debuggeeVMoptions, you don't want the same flags.
>
> Of course when we do want it we need a mechanism to allow it. The 
> shell scripts could access env variables set by jtreg. I think Java 
> code can access system properties with the same info. This then needs 
> to be passed through to the Processtools.
>
> Just as an aside: note also that jtreg doesn't know when 
> -javaoptions/-vmoptions is passing a VM selection flag (-client, 
> -server, -minimal) or mode flag (Xcomp, Xint, Xmixed) and so the 
> version info in the jtr file is often wrong.
>
> Cheers,
> David
>
>> Dan
>>
>>
>> On 8/26/13 7:38 AM, Leonid Mesnik wrote:
>>> Dan
>>>
>>> ProcessTools.createJavaProcessBuilder don't use test java options. 
>>> So all java invocations are always in '-Xmixed'.
>>>
>>> Leonid
>>>
>>> On 08/26/2013 05:12 PM, Aleksey Shipilev wrote:
>>>> Hi Dan,
>>>>
>>>> On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
>>>>> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>>>>> Here's the webrev:
>>>>>>     http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>>>>> hotspot/test/runtime/contended/Options.java
>>>>>      I count 11 Java process invocations. Will the default timeout
>>>>>      of 120 seconds be enough for a fastdebug '-server -Xcomp'
>>>>>      run on something like Solaris SPARC.
>>>> Linux i5/x86_64 laptop passes this test in 5 seconds. I think there 
>>>> is enough headroom for slower machines.
>>>>
>>>>>      The fragments:
>>>>>
>>>>>          "must be the between"
>>>>>          "must be the multiple of 8"
>>>>>
>>>>>      probably match the real error messages, but those messages
>>>>>      aren't quite proper English. I expected:
>>>>>
>>>>>          "must be in between"
>>>>>          "must be a multiple of 8"
>>>> Yes. Unfortunately, this is what VM outputs. Does it make sense to 
>>>> fix the error messages in VM along with the regression test? If so, 
>>>> here is the new webrev:
>>>>    http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>>>>
>>>> -Aleksey.
>>>
>>>
>>


--
Leonid Mesnik
JVM SQE



From staffan.larsen at oracle.com  Tue Aug 27 05:35:03 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 27 Aug 2013 14:35:03 +0200
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <008201cea321$0c337430$249a5c90$@oracle.com>
References: <52174654.8020400@oracle.com>
	<5217C296.7070807@oracle.com>	<521B544E.6090201@oracle.com>
	<521B5A65.40701@oracle.com>	<521B5B0B.30709@oracle.com>
	<521C21F6.90003@oracle.com> <521C9622.8060403@oracle.com>
	<008201cea321$0c337430$249a5c90$@oracle.com>
Message-ID: <6CCD1DDA-E398-4607-BAA7-97000164DA38@oracle.com>

Could we have a helper for this in ProcessTools? In case you forget what the property is called again.

/Staffan

On 27 aug 2013, at 14:29, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:

> No, we should not update ProcessTools with this, many of the tests that use
> ProcessTools need explicit control over the command line. The ones that
> should pass on javaopts should add the test.java.opts themselves to the
> arguments passed to the child process.
> 
> / Christian
> 
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net
> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Leonid
> Mesnik
> Sent: Tuesday, August 27, 2013 2:06 PM
> To: David Holmes
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR (S) CR 8023638: Add the regression test for 8006997
> 
> We should update ProcessTools so it add
> 'System.getProperty("test.java.opts")'  to test java options.
> 
> Also some of combinations are invalid and test should silently pass
> (skip) in such case.
> For example tests on CMS should just pass when we test any other GC and
> specify this as -javaoption.
> 
> 
> Leonid
> 
> On 08/27/2013 07:50 AM, David Holmes wrote:
>> On 26/08/2013 11:41 PM, Daniel D. Daugherty wrote:
>>> So when we're trying to test with -Xcomp we actually don't?
>>> That sounds rather wrong to me.
>> 
>> This is a general problem we are facing with tests that launch other 
>> VMs. The initial test gets invoked with a bunch of flags from the 
>> current "test configuration" but these don't get passed through to the 
>> launched VM. There is a bug open for this:
>> 
>> 8019502 The tests which launch Java from code should be modified to 
>> launch Java with options used to run the testing Java
>> 
>> but it isn't a black and white situation. Sometimes, like with your 
>> debuggeeVMoptions, you don't want the same flags.
>> 
>> Of course when we do want it we need a mechanism to allow it. The 
>> shell scripts could access env variables set by jtreg. I think Java 
>> code can access system properties with the same info. This then needs 
>> to be passed through to the Processtools.
>> 
>> Just as an aside: note also that jtreg doesn't know when 
>> -javaoptions/-vmoptions is passing a VM selection flag (-client, 
>> -server, -minimal) or mode flag (Xcomp, Xint, Xmixed) and so the 
>> version info in the jtr file is often wrong.
>> 
>> Cheers,
>> David
>> 
>>> Dan
>>> 
>>> 
>>> On 8/26/13 7:38 AM, Leonid Mesnik wrote:
>>>> Dan
>>>> 
>>>> ProcessTools.createJavaProcessBuilder don't use test java options. 
>>>> So all java invocations are always in '-Xmixed'.
>>>> 
>>>> Leonid
>>>> 
>>>> On 08/26/2013 05:12 PM, Aleksey Shipilev wrote:
>>>>> Hi Dan,
>>>>> 
>>>>> On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
>>>>>> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>>>>>> Here's the webrev:
>>>>>>>    http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>>>>>> hotspot/test/runtime/contended/Options.java
>>>>>>     I count 11 Java process invocations. Will the default timeout
>>>>>>     of 120 seconds be enough for a fastdebug '-server -Xcomp'
>>>>>>     run on something like Solaris SPARC.
>>>>> Linux i5/x86_64 laptop passes this test in 5 seconds. I think there 
>>>>> is enough headroom for slower machines.
>>>>> 
>>>>>>     The fragments:
>>>>>> 
>>>>>>         "must be the between"
>>>>>>         "must be the multiple of 8"
>>>>>> 
>>>>>>     probably match the real error messages, but those messages
>>>>>>     aren't quite proper English. I expected:
>>>>>> 
>>>>>>         "must be in between"
>>>>>>         "must be a multiple of 8"
>>>>> Yes. Unfortunately, this is what VM outputs. Does it make sense to 
>>>>> fix the error messages in VM along with the regression test? If so, 
>>>>> here is the new webrev:
>>>>>   http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>>>>> 
>>>>> -Aleksey.
>>>> 
>>>> 
>>> 
> 
> 
> --
> Leonid Mesnik
> JVM SQE
> 
> 


From lois.foltan at oracle.com  Tue Aug 27 05:44:01 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Tue, 27 Aug 2013 08:44:01 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521C8E1D.5030802@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
Message-ID: <521C9F11.5010809@oracle.com>


On 8/27/2013 7:31 AM, David Holmes wrote:
> On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
>> On 2013-08-27 04:41, David Holmes wrote:
>>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>>> Please review the following fix:
>>>>
>>>> Internal webrev:
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>>
>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file 
>>>> produced &
>>>>           runtime/6878713/Test6878713.sh fails on mac
>>>>
>>>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>
>>>> Summary of fix:
>>>>      On MacOS, currently Hotspot is built specifying the -fcheck-new
>>>> command line option to the llvm-g++ compiler.
>>>>      The -fcheck-new option directs the compiler to "check that the
>>>> pointer returned by |operator new| is non-null
>>>>       before attempting to modify the storage allocated." The clang++
>>>> compiler does not support the
>>>>       -fcheck-new option.  To obtain similiar functionality when
>>>> building Hotspot with clang++, empty exception
>>>>       throw() specifications must be added to all user-defined 
>>>> operator
>>>> new()'s.
>>>
>>> We just spotted something related in the PPC64 port and were going the
>>> other way or removing these "spurious" throw() declarations.
>>>
>>> But this seems really ugly - is there really a need to specialize this
>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
>>> honour the nothrow() semantics?
>>>
>>> That said I thought we already handled this using the "const
>>> std::nothrow_t&  nothrow_constant" where needed? Our other operator new
>>> implementations shouldn't return NULL but will abort.
>>>
>>> So why do we need -fcheck-new or this empty throw() ?
>>
>> I guess that if the C++ compiler knows that operator new() will throw an
>> exception if an allocation fails then it doesn't need to emit code to
>> explicitly avoid calling the constructor.
>
> Yes that is what happens, but why do _we_ need it when ...
>
>> If we declare operator new() with an empty throw() we will also inform
>> the compiler that new can't throw an exception and therefore the
>> compiler needs to explicitly handle failed allocations.
>
> ... we have two kinds of operator new implementations (or at least we 
> _should_ only have two kinds):
>
> 1. Will abort on OOM (either ResourceArea exhaustion or Stack 
> exhaustion) and so never returns NULL
> 2. Can return NULL and uses std::nothrow to indicate that
>
> So we should not need this if the nothrow is acting as I think it 
> should. Have we missed places where nothrow is needed? Do we have 
> errant operator new definitions unrelated to the allocation base classes?
Hi David,

I think there may be some confusion about what std::nothrow_t is 
actually doing.  It provides a mechanism to overload operator new & 
delete in order to direct the compiler to prefer a function definition 
that also should contain an empty "throw()" specification.  Take for 
example the standard definition of the global ::operator new().  It 
actually looks like:

  * void * operator new <a00960.html#a1414bcdb34c39ce82fc84bc8d5287966>
    (std::size_t) throw (std::bad_alloc)
  * void * operator new <a00960.html#a940b606c7824b4d5dd121199c277d629>
    (std::size_t, const std::nothrow_t &) throw ()

When the std::nothrow_t parameter is passed to the global ::operator 
new() the invoked function is the one that also contains an empty 
throw() specification.  It is due to this empty throw() specification 
that directs or triggers the C++ compiler to generate the detection of 
NULL constructor prologue.   Specifying only the std::nothrow_t 
parameter to a class member user-defined ::operator new() does not 
indicate to a C++ compiler that the function does not throw an 
exception.  According to the c++98 standard, a function that will throw 
no exceptions should be delcared with an empty "throw()" list 
specification.  When first experimenting with a fix, I did just try to 
overload Hotspot's user-defined operator new() with the std:nothrow_t 
parameter.  As expected, the mere presence of this parameter did not 
trigger the clang++ compiler to generate NULL detection constructor 
prologue code.  Unfortunately, probably due to legacy code, some C++ 
compilers behave differently.  For example, I did confirm with Solaris 
C++ development, the Solaris C++ by default always generates constructor 
prologue code that detects NULL for class member user-defined operator 
new() even in a throw situation. G++ provides the -fcheck-new command 
line option.  It is due to these differences of behavior or Hotspot's 
build specification of -fcheck-new that has led us to believe that 
std::nothrow_t was providing something that it is not.

That said, I would also prefer what you propose, deciding on two kinds 
of operator new()'s that can be defined.  I did examine all of the 
user-defined operator new()'s within the code and I determined that only 
a very small number possibly could not return NULL.  Given this, 
factored in with the historical reliance on -fcheck-new for the g++ 
compilers, I decided the safe route for JDK 8 was to introduce the 
NOEXCEPT macro.

Lois
>
> David
> -----
>
>> The g++ man page states:
>>
>>         -fcheck-new
>>             Check that the pointer returned by "operator new" is
>> non-null before attempting to modify the storage allocated. This check
>> is normally unnecessary because the C++ standard specifies that
>>             "operator new" will only return 0 if it is declared throw(),
>> in which case the compiler will always check the return value even
>> without this option.  In all other cases, when "operator new"
>>             has a non-empty exception specification, memory exhaustion
>> is signalled by throwing "std::bad_alloc".  See also new (nothrow).
>>
>> /Mikael
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Tests:
>>>>
>>>>       Solaris: built fastdebug & product images
>>>>       Linux: built fastdebug & product images
>>>>       MacOS:  built fastdebug & product images using llvm-g++ - ran
>>>> JTREG
>>>>                      built fastdebug & product images using clang++ -
>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>>       Windows:  built fastdebug & product images with VS2010
>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130827/ff53f4c9/attachment-0001.html 

From leonid.mesnik at oracle.com  Tue Aug 27 06:01:23 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Tue, 27 Aug 2013 17:01:23 +0400
Subject: RFR (S) CR 8023638: Add the regression test for 8006997
In-Reply-To: <008201cea321$0c337430$249a5c90$@oracle.com>
References: <52174654.8020400@oracle.com>
	<5217C296.7070807@oracle.com>	<521B544E.6090201@oracle.com>
	<521B5A65.40701@oracle.com>	<521B5B0B.30709@oracle.com>
	<521C21F6.90003@oracle.com> <521C9622.8060403@oracle.com>
	<008201cea321$0c337430$249a5c90$@oracle.com>
Message-ID: <521CA323.2090706@oracle.com>

I think that passing test.java.opts should be done by default in 
createJavaProcessBuilder
and  tests which need explicit control should use non-default version of
createJavaProcessBuilder.

It is very easy to forget to add test.java.opts so it is better to make 
this by default.

Leonid

On 08/27/2013 04:29 PM, Christian Tornqvist wrote:
> No, we should not update ProcessTools with this, many of the tests that use
> ProcessTools need explicit control over the command line. The ones that
> should pass on javaopts should add the test.java.opts themselves to the
> arguments passed to the child process.
>
> / Christian
>
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net
> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Leonid
> Mesnik
> Sent: Tuesday, August 27, 2013 2:06 PM
> To: David Holmes
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR (S) CR 8023638: Add the regression test for 8006997
>
> We should update ProcessTools so it add
> 'System.getProperty("test.java.opts")'  to test java options.
>
> Also some of combinations are invalid and test should silently pass
> (skip) in such case.
> For example tests on CMS should just pass when we test any other GC and
> specify this as -javaoption.
>
>
> Leonid
>
> On 08/27/2013 07:50 AM, David Holmes wrote:
>> On 26/08/2013 11:41 PM, Daniel D. Daugherty wrote:
>>> So when we're trying to test with -Xcomp we actually don't?
>>> That sounds rather wrong to me.
>> This is a general problem we are facing with tests that launch other
>> VMs. The initial test gets invoked with a bunch of flags from the
>> current "test configuration" but these don't get passed through to the
>> launched VM. There is a bug open for this:
>>
>> 8019502 The tests which launch Java from code should be modified to
>> launch Java with options used to run the testing Java
>>
>> but it isn't a black and white situation. Sometimes, like with your
>> debuggeeVMoptions, you don't want the same flags.
>>
>> Of course when we do want it we need a mechanism to allow it. The
>> shell scripts could access env variables set by jtreg. I think Java
>> code can access system properties with the same info. This then needs
>> to be passed through to the Processtools.
>>
>> Just as an aside: note also that jtreg doesn't know when
>> -javaoptions/-vmoptions is passing a VM selection flag (-client,
>> -server, -minimal) or mode flag (Xcomp, Xint, Xmixed) and so the
>> version info in the jtr file is often wrong.
>>
>> Cheers,
>> David
>>
>>> Dan
>>>
>>>
>>> On 8/26/13 7:38 AM, Leonid Mesnik wrote:
>>>> Dan
>>>>
>>>> ProcessTools.createJavaProcessBuilder don't use test java options.
>>>> So all java invocations are always in '-Xmixed'.
>>>>
>>>> Leonid
>>>>
>>>> On 08/26/2013 05:12 PM, Aleksey Shipilev wrote:
>>>>> Hi Dan,
>>>>>
>>>>> On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
>>>>>> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>>>>>> Here's the webrev:
>>>>>>>      http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>>>>>> hotspot/test/runtime/contended/Options.java
>>>>>>       I count 11 Java process invocations. Will the default timeout
>>>>>>       of 120 seconds be enough for a fastdebug '-server -Xcomp'
>>>>>>       run on something like Solaris SPARC.
>>>>> Linux i5/x86_64 laptop passes this test in 5 seconds. I think there
>>>>> is enough headroom for slower machines.
>>>>>
>>>>>>       The fragments:
>>>>>>
>>>>>>           "must be the between"
>>>>>>           "must be the multiple of 8"
>>>>>>
>>>>>>       probably match the real error messages, but those messages
>>>>>>       aren't quite proper English. I expected:
>>>>>>
>>>>>>           "must be in between"
>>>>>>           "must be a multiple of 8"
>>>>> Yes. Unfortunately, this is what VM outputs. Does it make sense to
>>>>> fix the error messages in VM along with the regression test? If so,
>>>>> here is the new webrev:
>>>>>     http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>>>>>
>>>>> -Aleksey.
>>>>
>
> --
> Leonid Mesnik
> JVM SQE
>
>


-- 
Leonid Mesnik
JVM SQE


From jiangli.zhou at oracle.com  Tue Aug 27 07:40:58 2013
From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com)
Date: Tue, 27 Aug 2013 14:40:58 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130827144106.4713148BC3@hg.openjdk.java.net>

Changeset: 6b3ac96bada6
Author:    jiangli
Date:      2013-08-26 13:32 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6b3ac96bada6

8023477: Invalid CP index when reading ConstantPool.
Summary: Need to check for 0 case for InstanceKlass::_generic_signature_index.
Reviewed-by: sspitsyn, sla

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java

Changeset: b3596321fbf4
Author:    jiangli
Date:      2013-08-27 04:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b3596321fbf4

Merge



From jiangli.zhou at oracle.com  Tue Aug 27 08:27:44 2013
From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com)
Date: Tue, 27 Aug 2013 15:27:44 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 8014135: The JVMTI specification does
	not conform to recent changes in JNI specification
Message-ID: <20130827152752.E0FF148BC5@hg.openjdk.java.net>

Changeset: f92b82d454fa
Author:    bpittore
Date:      2013-08-23 20:33 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f92b82d454fa

8014135: The JVMTI specification does not conform to recent changes in JNI specification
Summary: Added support for statically linked agents
Reviewed-by: sspitsyn, bobv, coleenp

! src/os/posix/vm/os_posix.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/prims/jvmti.xml
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp


From lois.foltan at oracle.com  Tue Aug 27 09:18:21 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Tue, 27 Aug 2013 12:18:21 -0400
Subject: RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV in
	Unsafe_SetByte+0x35
In-Reply-To: <521BFA78.9070908@oracle.com>
References: <521BFA78.9070908@oracle.com>
Message-ID: <521CD14D.5040809@oracle.com>

Please review the following fix:
     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/

Bug:
     bug link at https://bugs.openjdk.java.net/browse/JDK-8022407

Summary of fix:

The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ 
compiler, exhibited a compiler optimization issue when prims/unsafe.cpp 
was compiled at the default -Os level. As a work around fix, knock the 
optimization level down down to -O0.

Tests:
     MacOS: built fastdebug & product images using clang++ (ran JTREG & 
vm.quick.testlist)
                    built using llvm-g++ to verify prims/unsafe.cpp 
remained compiled at -Os

Thank you,
Lois



From tao.mao at oracle.com  Tue Aug 27 10:13:54 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Tue, 27 Aug 2013 10:13:54 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521C5CC8.5060102@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>
Message-ID: <521CDE52.2030407@oracle.com>



On 8/27/13 1:01 AM, Bengt Rutisson wrote:
>
> Yumin,
>
> On 8/26/13 7:01 PM, Yumin Qi wrote:
>> Bengt,
>>
>>   Thanks for your comments.
>>   Yes, as you said, the purpose of rotating logs is primarily 
>> targeted for saving disk space. This bug is supplying  customers 
>> another option to prevent the previous gc logs from removed by 
>> restart app without making copy. Now with this pid and time stamp 
>> included in file name,  we have more options for users. It is up to 
>> user to make decision to or not to keep the logs. We cannot handle 
>> all the requests in JVM, but we can offer the choices for users I 
>> think. Any way, with either the previous rotating version, or the one 
>> I am working, the logs will not grow constantly without limit to blow 
>> storage out as long as users give enough attention.
>>
>>   My concern is for no log rotation, should we still use time stamp 
>> in file name? I have one version for this, I hope get more comments 
>> for that.
>
> Sorry if I wasn't clear before. I am not worried about the case when 
> log rotation is turned on. What I was worried about was the case where 
> a user is not using log rotation but is still piping the GC output to 
> a file. That file will be overwritten every time the VM is restarted. 
> If we add time stamps to the file name for this case then the file 
> will not be overwritten. I think that is a bit of a scary change. 
> That's all.

If you are worried about the case where a user is not using log rotation 
but creating a new file for each restart, you should be almost 
equivalently worried about the case where a user is using log rotation 
and having many rotated logs created which are different for each VM 
restart. Basically, we are creating even more files over time, which 
falls into your concern.

At this point, I'm fine with either choice for they have pros and cons. 
If we always append date and time to log file names, customers may say 
"the logs are 'eating' my disk"; if you don't do that, the customers 
would still complain the log is overwritten after a restart (I saw these 
kinds of CR's twice).

Thanks.
Tao

>
> Bengt
>
>>
>>   More comments are appreciated by sending to more wide audience, 
>> especially sustaining, they have more experience with customer request.
>>
>> Thanks
>> Yumin
>>
>>
>>
>> On 8/26/2013 4:47 AM, Bengt Rutisson wrote:
>>>
>>> Hi Yumin and Tao,
>>>
>>> I have not reviewed the code change but I have a comment inlined below.
>>>
>>> On 8/24/13 1:05 AM, Yumin Qi wrote:
>>>> Tao,
>>>>
>>>>   Thanks for your review.
>>>>
>>>> On 8/23/2013 3:33 PM, Tao Mao wrote:
>>>>> Hi,
>>>>>
>>>>> I reviewed most of the code and test-ran a build from it. It's a 
>>>>> very cool and important improvement.
>>>>>
>>>>> Thank you for putting together these on our wishlist for long.
>>>>>
>>>>> Below are some comments.
>>>>>
>>>>> 1. src/share/vm/runtime/arguments.cpp
>>>>>
>>>>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>>>>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>>>>
>>>>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>>>>
>>>>> I worked on a problem of enabling gc log limit over 2G 
>>>>> (JDK-7122222). So it seems that customers sometimes want gc logs 
>>>>> to be very large.
>>>>>
>>>> Sure, will add.
>>>>> 2. src/share/vm/runtime/arguments.hpp
>>>>>
>>>>> (1) with the current changeset, we only append date&time to 
>>>>> file_name w/ +UseGCLogFileRotation; if not, we won't have 
>>>>> date&time info.
>>>>>
>>>>> I think it would be useful to let both cases (w/ and w/o 
>>>>> UseGCLogFileRotation) have date&time in order to solve the 
>>>>> overwritten problem (e.g. JDK-8020667). In fact, having that, we 
>>>>> actually solve JDK-8020667.
>>>>>
>>>>> If you want to have that, basically you need to work on the 
>>>>> FileStream constructor methods fileStream().
>>>>>
>>>> I can change that, if no objection from others. This also will 
>>>> simplify the setting of file name here.
>>>
>>> I think appending a timestamp to the log file name is a nice idea, 
>>> but I think it is also a bit scary. There are users who restart 
>>> their applications regularly. With the suggested idea such users 
>>> will now risk filling up their disk space with log files. I imagine 
>>> that that will not be appreciated by everyone. Such a change should 
>>> probably be discussed more thoroughly than just in a review request.
>>>
>>> Thanks,
>>> Bengt
>>>
>>>
>>>>
>>>>> (2) Would it be better to rename method name reformat_filename() 
>>>>> to extend_filename()?
>>>>>
>>>>> (3) Typos and suggestion
>>>>> 537 // rotate file in names filename.0, filename.1, ..., 
>>>>> filename.<NumberOfGCLogFiles - 1>
>>>>> *=> extended_filename.0*
>>>>>
>>>>> 538 // filename contains pid and time when the fist file created. 
>>>>> The current filename is
>>>>> *=> *the*first *file created.
>>>>>
>>>>> 539 // gc_log_file_name + pid<pid> + 
>>>>> YYYY-MM-DD_HH-MM-SS.<i>.current, where i is current
>>>>> 540 // rotation file number. After it reaches max file size, the 
>>>>> file will be saved and
>>>>> 541 // renamed with .current removed from its tail.
>>>>>
>>>> Will change that.
>>>>> 3. For your point 5), I don't quite get it. In my test-run, I 
>>>>> tried to change file permission to unreadable and unwritable, but 
>>>>> VM would later change the permission back anyway.
>>>>>
>>>>> So could you bring up some use cases of that functionality to give 
>>>>> more details?
>>>>>
>>>> Changing file permission will not stop the file create, in this 
>>>> rotation, the file opened/saved/removed/renamed -> then repeat. 
>>>> What I have done is change the while directory to read only, then 
>>>> the create failed so rotation stopped.
>>>>
>>>>> 4. Will you write jtreg tests for this functionality? It looks 
>>>>> possible to write some tests, at least checking the format of log 
>>>>> names.
>>>>>
>>>> Good suggestion, I will add one.
>>>>
>>>>> Thanks.
>>>>> Tao
>>>>>
>>>>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>>>>> Could I get  a GC staff review the change? Need more reviewers to 
>>>>>> push this in.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>>>>> Hi, all
>>>>>>>
>>>>>>>   This is second version after feedback from first round.
>>>>>>>   The changes are:
>>>>>>>
>>>>>>>   1) file name will be based on gc log file name 
>>>>>>> (-Xloggc:filename), pid (process id) and time when the first 
>>>>>>> rotation file created:
>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>>>>   2) If rotate in same file, file name is as in 1), if rotate in 
>>>>>>> multiple files, .<i> will append to above file name.
>>>>>>>   3) every time file rotated, file name and time when file 
>>>>>>> created will be logged to head/tail, this is same as first version.
>>>>>>>   4) current file has name 
>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>>>>        This is similar to first version.
>>>>>>>        By adapting such name format we will never loss logs in 
>>>>>>> case apps stops and restart, the log files will not be 
>>>>>>> overwritten since time stamp in file names.
>>>>>>>    5) If open file failed, turn off gc log rotation.
>>>>>>>         If due to some reason, file operation failed (such as 
>>>>>>> permission changed etc), with log file opened, logging still 
>>>>>>> works, but at
>>>>>>>         saving and renaming, the file operation will fail, this 
>>>>>>> will lead not all files saved.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>>>>
>>>>>>>      Tested with jtreg, JPRT.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>   Can I have your review for this small changes?
>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>>>>
>>>>>>>>    This is for a enhancement to add head/tail message to the 
>>>>>>>> logging files to assist reading GC output.
>>>>>>>>    1. modified prompt message if invalid arguments used for log 
>>>>>>>> rotating;
>>>>>>>>    2. add time and file name message to log file head/tail.
>>>>>>>>    3. for easily identify which log file is current, use file 
>>>>>>>> name like <filename>.n.current, after it reaches maximum size, 
>>>>>>>> rename it to <filename>.n
>>>>>>>>         On Windows, there is no F_OK (existing test) 
>>>>>>>> definition, F_OK is defined as "0" and for _access of VC++, it 
>>>>>>>> just describes:
>>>>>>>>
>>>>>>>> modevalue
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Checks file for
>>>>>>>>
>>>>>>>> 00
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Existence only
>>>>>>>>
>>>>>>>> 02
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Write-only
>>>>>>>>
>>>>>>>> 04
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Read-only
>>>>>>>>
>>>>>>>> 06
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Read and write
>>>>>>>>
>>>>>>>>
>>>>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>>>>> The definition are consistent with unistd.h.
>>>>>>>>
>>>>>>>>     Test: JPRT and jtreg.
>>>>>>>>
>>>>>>>>    Thanks
>>>>>>>>    Yumin
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>

From christian.thalinger at oracle.com  Tue Aug 27 10:29:03 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 27 Aug 2013 10:29:03 -0700
Subject: RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV in
	Unsafe_SetByte+0x35
In-Reply-To: <521CD14D.5040809@oracle.com>
References: <521BFA78.9070908@oracle.com> <521CD14D.5040809@oracle.com>
Message-ID: <5CDAD4D1-5A6C-45EC-AAF3-4CB09FD76344@oracle.com>


On Aug 27, 2013, at 9:18 AM, Lois Foltan <lois.foltan at oracle.com> wrote:

> Please review the following fix:
>    open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/
> 
> Bug:
>    bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
> 
> Summary of fix:
> 
> The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ compiler, exhibited a compiler optimization issue when prims/unsafe.cpp was compiled at the default -Os level. As a work around fix, knock the optimization level down down to -O0.

Why are we lowering to -O0 when you state in the bug report that -O1 also works?  What is the code that breaks?

-- Chris

> 
> Tests:
>    MacOS: built fastdebug & product images using clang++ (ran JTREG & vm.quick.testlist)
>                   built using llvm-g++ to verify prims/unsafe.cpp remained compiled at -Os
> 
> Thank you,
> Lois
> 
> 


From christian.thalinger at oracle.com  Tue Aug 27 10:49:12 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 27 Aug 2013 10:49:12 -0700
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521C9F11.5010809@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
	<521C9F11.5010809@oracle.com>
Message-ID: <B701E9CB-624F-4CF4-9C40-B2A717254400@oracle.com>


On Aug 27, 2013, at 5:44 AM, Lois Foltan <lois.foltan at oracle.com> wrote:

> 
> On 8/27/2013 7:31 AM, David Holmes wrote:
>> On 27/08/2013 6:01 PM, Mikael Gerdin wrote: 
>>> On 2013-08-27 04:41, David Holmes wrote: 
>>>> On 27/08/2013 4:36 AM, Lois Foltan wrote: 
>>>>> Please review the following fix: 
>>>>> 
>>>>> Internal webrev: 
>>>>> 
>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/ 
>>>>> 
>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced & 
>>>>>           runtime/6878713/Test6878713.sh fails on mac 
>>>>> 
>>>>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140 
>>>>> 
>>>>> Summary of fix: 
>>>>>      On MacOS, currently Hotspot is built specifying the -fcheck-new 
>>>>> command line option to the llvm-g++ compiler. 
>>>>>      The -fcheck-new option directs the compiler to "check that the 
>>>>> pointer returned by |operator new| is non-null 
>>>>>       before attempting to modify the storage allocated."  The clang++ 
>>>>> compiler does not support the 
>>>>>       -fcheck-new option.  To obtain similiar functionality when 
>>>>> building Hotspot with clang++, empty exception 
>>>>>       throw() specifications must be added to all user-defined operator 
>>>>> new()'s. 
>>>> 
>>>> We just spotted something related in the PPC64 port and were going the 
>>>> other way or removing these "spurious" throw() declarations. 
>>>> 
>>>> But this seems really ugly - is there really a need to specialize this 
>>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers 
>>>> honour the nothrow() semantics? 
>>>> 
>>>> That said I thought we already handled this using the "const 
>>>> std::nothrow_t&  nothrow_constant" where needed? Our other operator new 
>>>> implementations shouldn't return NULL but will abort. 
>>>> 
>>>> So why do we need -fcheck-new or this empty throw() ? 
>>> 
>>> I guess that if the C++ compiler knows that operator new() will throw an 
>>> exception if an allocation fails then it doesn't need to emit code to 
>>> explicitly avoid calling the constructor. 
>> 
>> Yes that is what happens, but why do _we_ need it when ... 
>> 
>>> If we declare operator new() with an empty throw() we will also inform 
>>> the compiler that new can't throw an exception and therefore the 
>>> compiler needs to explicitly handle failed allocations. 
>> 
>> ... we have two kinds of operator new implementations (or at least we _should_ only have two kinds): 
>> 
>> 1. Will abort on OOM (either ResourceArea exhaustion or Stack exhaustion) and so never returns NULL 
>> 2. Can return NULL and uses std::nothrow to indicate that 
>> 
>> So we should not need this if the nothrow is acting as I think it should. Have we missed places where nothrow is needed? Do we have errant operator new definitions unrelated to the allocation base classes? 
> Hi David,
> 
> I think there may be some confusion about what std::nothrow_t is actually doing.  It provides a mechanism to overload operator new & delete in order to direct the compiler to prefer a function definition that also should contain an empty "throw()" specification.  Take for example the standard definition of the global ::operator new().  It actually looks like:
> void * operator new (std::size_t) throw (std::bad_alloc)
> void * operator new (std::size_t, const std::nothrow_t &) throw ()
> When the std::nothrow_t parameter is passed to the global ::operator new() the invoked function is the one that also contains an empty throw() specification.  It is due to this empty throw() specification that directs or triggers the C++ compiler to generate the detection of NULL constructor prologue.   Specifying only the std::nothrow_t parameter to a class member user-defined ::operator new() does not indicate to a C++ compiler that the function does not throw an exception.  According to the c++98 standard, a function that will throw no exceptions should be delcared with an empty "throw()" list specification.  When first experimenting with a fix, I did just try to overload Hotspot's user-defined operator new() with the std:nothrow_t parameter.  As expected, the mere presence of this parameter did not trigger the clang++ compiler to generate NULL detection constructor prologue code.  Unfortunately, probably due to legacy code, some C++ compilers behave differently.  For example, I did confirm with Solaris C++ development, the Solaris C++ by default always generates constructor prologue code that detects NULL for class member user-defined operator new() even in a throw situation.  G++ provides the -fcheck-new command line option.  It is due to these differences of behavior or Hotspot's build specification of -fcheck-new that has led us to believe that std::nothrow_t was providing something that it is not.
> 
> That said, I would also prefer what you propose, deciding on two kinds of operator new()'s that can be defined.  I did examine all of the user-defined operator new()'s within the code and I determined that only a very small number possibly could not return NULL.  Given this, factored in with the historical reliance on -fcheck-new for the g++ compilers, I decided the safe route for JDK 8 was to introduce the NOEXCEPT macro.

Why can't we use throw() with all compilers?  Just because we are using -fcheck-new for GCC?

-- Chris

> 
> Lois
>> 
>> David 
>> ----- 
>> 
>>> The g++ man page states: 
>>> 
>>>         -fcheck-new 
>>>             Check that the pointer returned by "operator new" is 
>>> non-null before attempting to modify the storage allocated.  This check 
>>> is normally unnecessary because the C++ standard specifies that 
>>>             "operator new" will only return 0 if it is declared throw(), 
>>> in which case the compiler will always check the return value even 
>>> without this option.  In all other cases, when "operator new" 
>>>             has a non-empty exception specification, memory exhaustion 
>>> is signalled by throwing "std::bad_alloc".  See also new (nothrow). 
>>> 
>>> /Mikael 
>>> 
>>>> 
>>>> Thanks, 
>>>> David 
>>>> 
>>>>> Tests: 
>>>>> 
>>>>>       Solaris: built fastdebug & product images 
>>>>>       Linux: built fastdebug & product images 
>>>>>       MacOS:  built fastdebug & product images using llvm-g++ - ran 
>>>>> JTREG 
>>>>>                      built fastdebug & product images using clang++ - 
>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress) 
>>>>>       Windows:  built fastdebug & product images with VS2010 
>>>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130827/0f15eaed/attachment.html 

From karen.kinnear at oracle.com  Tue Aug 27 11:25:04 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 27 Aug 2013 14:25:04 -0400
Subject: XS RFR: 8020489: Lambda: VM crash when non-existent interface method
	called by invokespecial
In-Reply-To: <9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
Message-ID: <9E0D4E5C-FEE1-4384-8998-A0A5D70326E2@oracle.com>

Please review:

webrev: http://cr.openjdk.java.net/~acorn/8020489/webrev/
http://bugs.sun.com/view_bug.do?bug_id=8020489

tests:
jck test in bug report
defmeth tests (no new failures)
vm.quick.testlist in progress
jprt in progress

thanks,
Karen



From kamggg at gmail.com  Tue Aug 27 11:46:54 2013
From: kamggg at gmail.com (Keith McGuigan)
Date: Tue, 27 Aug 2013 14:46:54 -0400
Subject: XS RFR: 8020489: Lambda: VM crash when non-existent interface
	method called by invokespecial
In-Reply-To: <9E0D4E5C-FEE1-4384-8998-A0A5D70326E2@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
	<9E0D4E5C-FEE1-4384-8998-A0A5D70326E2@oracle.com>
Message-ID: <CAFUO74=S8aMs2CKza6U1TRQ+q95a5Tt_wP3JDcgPrBTW_dsOTw@mail.gmail.com>

Looks good.

--
- Keith


On Tue, Aug 27, 2013 at 2:25 PM, Karen Kinnear <karen.kinnear at oracle.com>wrote:

> Please review:
>
> webrev: http://cr.openjdk.java.net/~acorn/8020489/webrev/
> http://bugs.sun.com/view_bug.do?bug_id=8020489
>
> tests:
> jck test in bug report
> defmeth tests (no new failures)
> vm.quick.testlist in progress
> jprt in progress
>
> thanks,
> Karen
>
>
>


-- 
- Keith McGuigan <keith.mcguigan at alumni.unh.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130827/62852416/attachment.html 

From coleen.phillimore at oracle.com  Tue Aug 27 12:00:57 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 27 Aug 2013 15:00:57 -0400
Subject: XS RFR: 8020489: Lambda: VM crash when non-existent interface
	method called by invokespecial
In-Reply-To: <9E0D4E5C-FEE1-4384-8998-A0A5D70326E2@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
	<9E0D4E5C-FEE1-4384-8998-A0A5D70326E2@oracle.com>
Message-ID: <521CF769.3040103@oracle.com>


Looks good.
Coleen

On 08/27/2013 02:25 PM, Karen Kinnear wrote:
> Please review:
>
> webrev: http://cr.openjdk.java.net/~acorn/8020489/webrev/
> http://bugs.sun.com/view_bug.do?bug_id=8020489
>
> tests:
> jck test in bug report
> defmeth tests (no new failures)
> vm.quick.testlist in progress
> jprt in progress
>
> thanks,
> Karen
>
>


From lois.foltan at oracle.com  Tue Aug 27 12:39:09 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Tue, 27 Aug 2013 15:39:09 -0400
Subject: RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV in
	Unsafe_SetByte+0x35
In-Reply-To: <5CDAD4D1-5A6C-45EC-AAF3-4CB09FD76344@oracle.com>
References: <521BFA78.9070908@oracle.com> <521CD14D.5040809@oracle.com>
	<5CDAD4D1-5A6C-45EC-AAF3-4CB09FD76344@oracle.com>
Message-ID: <521D005D.4050004@oracle.com>


On 8/27/2013 1:29 PM, Christian Thalinger wrote:
> On Aug 27, 2013, at 9:18 AM, Lois Foltan <lois.foltan at oracle.com> wrote:
>
>> Please review the following fix:
>>     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/
>>
>> Bug:
>>     bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>
>> Summary of fix:
>>
>> The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ compiler, exhibited a compiler optimization issue when prims/unsafe.cpp was compiled at the default -Os level. As a work around fix, knock the optimization level down down to -O0.
> Why are we lowering to -O0 when you state in the bug report that -O1 also works?  What is the code that breaks?
>
> -- Chris
Hi Chris,
The convention within make/bsd/makefiles/gcc.make indicated that 
historically files that exhibited C++ compiler optimization issues were 
knocked down to /NOOPT or -O0.  I did also check with Coleen to make 
sure that prims/unsafe.cpp was not a performance critical file.  -O1 
does add some optimizations on top of -O0 but not inlining.  I will 
recheck testing with -O1 to confirm and change unsafe.cpp's optimization 
level to -O1 if testing yields good results.

I suspect the optimization problem is in unsafe.cpp's definition of 
Unsafe_GetNativeByte.  I had left off tracking it at that level and 
certainly will not close the JDK bug until I can narrow in further and 
hopefully report to the clang compiler team.

Thanks,
Lois
>> Tests:
>>     MacOS: built fastdebug & product images using clang++ (ran JTREG & vm.quick.testlist)
>>                    built using llvm-g++ to verify prims/unsafe.cpp remained compiled at -Os
>>
>> Thank you,
>> Lois
>>
>>


From lois.foltan at oracle.com  Tue Aug 27 12:42:41 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Tue, 27 Aug 2013 15:42:41 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <B701E9CB-624F-4CF4-9C40-B2A717254400@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
	<521C9F11.5010809@oracle.com>
	<B701E9CB-624F-4CF4-9C40-B2A717254400@oracle.com>
Message-ID: <521D0131.1040201@oracle.com>


On 8/27/2013 1:49 PM, Christian Thalinger wrote:
>
> On Aug 27, 2013, at 5:44 AM, Lois Foltan <lois.foltan at oracle.com 
> <mailto:lois.foltan at oracle.com>> wrote:
>
>>
>> On 8/27/2013 7:31 AM, David Holmes wrote:
>>> On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
>>>> On 2013-08-27 04:41, David Holmes wrote:
>>>>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>>>>> Please review the following fix:
>>>>>>
>>>>>> Internal webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>>>>
>>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file 
>>>>>> produced &
>>>>>>           runtime/6878713/Test6878713.sh fails on mac
>>>>>>
>>>>>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>>>
>>>>>> Summary of fix:
>>>>>>      On MacOS, currently Hotspot is built specifying the -fcheck-new
>>>>>> command line option to the llvm-g++ compiler.
>>>>>>      The -fcheck-new option directs the compiler to "check that the
>>>>>> pointer returned by |operator new| is non-null
>>>>>>       before attempting to modify the storage allocated."  The 
>>>>>> clang++
>>>>>> compiler does not support the
>>>>>>       -fcheck-new option.  To obtain similiar functionality when
>>>>>> building Hotspot with clang++, empty exception
>>>>>>       throw() specifications must be added to all user-defined 
>>>>>> operator
>>>>>> new()'s.
>>>>>
>>>>> We just spotted something related in the PPC64 port and were going 
>>>>> the
>>>>> other way or removing these "spurious" throw() declarations.
>>>>>
>>>>> But this seems really ugly - is there really a need to specialize 
>>>>> this
>>>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
>>>>> honour the nothrow() semantics?
>>>>>
>>>>> That said I thought we already handled this using the "const
>>>>> std::nothrow_t&  nothrow_constant" where needed? Our other 
>>>>> operator new
>>>>> implementations shouldn't return NULL but will abort.
>>>>>
>>>>> So why do we need -fcheck-new or this empty throw() ?
>>>>
>>>> I guess that if the C++ compiler knows that operator new() will 
>>>> throw an
>>>> exception if an allocation fails then it doesn't need to emit code to
>>>> explicitly avoid calling the constructor.
>>>
>>> Yes that is what happens, but why do _we_ need it when ...
>>>
>>>> If we declare operator new() with an empty throw() we will also inform
>>>> the compiler that new can't throw an exception and therefore the
>>>> compiler needs to explicitly handle failed allocations.
>>>
>>> ... we have two kinds of operator new implementations (or at least 
>>> we _should_ only have two kinds):
>>>
>>> 1. Will abort on OOM (either ResourceArea exhaustion or Stack 
>>> exhaustion) and so never returns NULL
>>> 2. Can return NULL and uses std::nothrow to indicate that
>>>
>>> So we should not need this if the nothrow is acting as I think it 
>>> should. Have we missed places where nothrow is needed? Do we have 
>>> errant operator new definitions unrelated to the allocation base 
>>> classes?
>> Hi David,
>>
>> I think there may be some confusion about what std::nothrow_t is 
>> actually doing.  It provides a mechanism to overload operator new & 
>> delete in order to direct the compiler to prefer a function 
>> definition that also should contain an empty "throw()" 
>> specification.  Take for example the standard definition of the 
>> global ::operator new().  It actually looks like:
>>
>>   * void * operator new
>>     <x-msg://14159/a00960.html#a1414bcdb34c39ce82fc84bc8d5287966>
>>     (std::size_t) throw (std::bad_alloc)
>>   * void * operator new
>>     <x-msg://14159/a00960.html#a940b606c7824b4d5dd121199c277d629>
>>     (std::size_t, const std::nothrow_t &) throw ()
>>
>> When the std::nothrow_t parameter is passed to the global ::operator 
>> new() the invoked function is the one that also contains an empty 
>> throw() specification.  It is due to this empty throw() specification 
>> that directs or triggers the C++ compiler to generate the detection 
>> of NULL constructor prologue.   Specifying only the std::nothrow_t 
>> parameter to a class member user-defined ::operator new() does not 
>> indicate to a C++ compiler that the function does not throw an 
>> exception.  According to the c++98 standard, a function that will 
>> throw no exceptions should be delcared with an empty "throw()" list 
>> specification.  When first experimenting with a fix, I did just try 
>> to overload Hotspot's user-defined operator new() with the 
>> std:nothrow_t parameter.  As expected, the mere presence of this 
>> parameter did not trigger the clang++ compiler to generate NULL 
>> detection constructor prologue code.  Unfortunately, probably due to 
>> legacy code, some C++ compilers behave differently.  For example, I 
>> did confirm with Solaris C++ development, the Solaris C++ by default 
>> always generates constructor prologue code that detects NULL for 
>> class member user-defined operator new() even in a throw situation.  
>> G++ provides the -fcheck-new command line option.  It is due to these 
>> differences of behavior or Hotspot's build specification of 
>> -fcheck-new that has led us to believe that std::nothrow_t was 
>> providing something that it is not.
>>
>> That said, I would also prefer what you propose, deciding on two 
>> kinds of operator new()'s that can be defined.  I did examine all of 
>> the user-defined operator new()'s within the code and I determined 
>> that only a very small number possibly could not return NULL.  Given 
>> this, factored in with the historical reliance on -fcheck-new for the 
>> g++ compilers, I decided the safe route for JDK 8 was to introduce 
>> the NOEXCEPT macro.
>
> Why can't we use throw() with all compilers?  Just because we are 
> using -fcheck-new for GCC?
Hi Chris,

Yes certainly that would be preferable to the NOEXCEPT macro.  I also 
believe most modern C++ compilers support the c++98 standard at this 
point and would handle the empty throw() specification correctly.  
However, after discussing with Coleen, it was thought that in order to 
limit the scope of this change for JDK 8 introducing the NOEXCEPT macro 
was again the safer route.

Thanks,
Lois

>
> -- Chris
>
>>
>> Lois
>>>
>>> David
>>> -----
>>>
>>>> The g++ man page states:
>>>>
>>>>         -fcheck-new
>>>>             Check that the pointer returned by "operator new" is
>>>> non-null before attempting to modify the storage allocated.  This 
>>>> check
>>>> is normally unnecessary because the C++ standard specifies that
>>>>             "operator new" will only return 0 if it is declared 
>>>> throw(),
>>>> in which case the compiler will always check the return value even
>>>> without this option.  In all other cases, when "operator new"
>>>>             has a non-empty exception specification, memory exhaustion
>>>> is signalled by throwing "std::bad_alloc".  See also new (nothrow).
>>>>
>>>> /Mikael
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Tests:
>>>>>>
>>>>>>       Solaris: built fastdebug & product images
>>>>>>       Linux: built fastdebug & product images
>>>>>>       MacOS:  built fastdebug & product images using llvm-g++ - ran
>>>>>> JTREG
>>>>>>                      built fastdebug & product images using 
>>>>>> clang++ -
>>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>>>>       Windows:  built fastdebug & product images with VS2010
>>>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130827/0459858c/attachment-0001.html 

From yumin.qi at oracle.com  Tue Aug 27 12:59:35 2013
From: yumin.qi at oracle.com (yumin.qi at oracle.com)
Date: Tue, 27 Aug 2013 19:59:35 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130827195941.CD15548BF0@hg.openjdk.java.net>

Changeset: 7e7dd25666da
Author:    ccheung
Date:      2013-08-26 14:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7e7dd25666da

8020675: invalid jar file in the bootclasspath could lead to jvm fatal error
Summary: removed offending EXCEPTION_MARK calls and code cleanup
Reviewed-by: dholmes, iklam, coleenp, mseledtsov

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoader.hpp
+ test/runtime/LoadClass/LoadClassNegative.java
+ test/runtime/LoadClass/TestForName.java
+ test/runtime/LoadClass/dummy.jar

Changeset: 5351fe805c12
Author:    minqi
Date:      2013-08-27 07:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5351fe805c12

Merge



From karen.kinnear at oracle.com  Tue Aug 27 13:10:28 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 27 Aug 2013 16:10:28 -0400
Subject: XS RFR: 8020489: Lambda: VM crash when non-existent interface
	method called by invokespecial
In-Reply-To: <CAFUO74=S8aMs2CKza6U1TRQ+q95a5Tt_wP3JDcgPrBTW_dsOTw@mail.gmail.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
	<9E0D4E5C-FEE1-4384-8998-A0A5D70326E2@oracle.com>
	<CAFUO74=S8aMs2CKza6U1TRQ+q95a5Tt_wP3JDcgPrBTW_dsOTw@mail.gmail.com>
Message-ID: <E60CDB54-B7EB-4E8F-B569-47ABA7C74034@oracle.com>

Thank you for the review - ok it really makes me smile to have you looking at this code. 
Much appreciated.

thanks,
Karen

On Aug 27, 2013, at 2:46 PM, Keith McGuigan wrote:

> Looks good.
>  
> --
> - Keith
> 
> 
> On Tue, Aug 27, 2013 at 2:25 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> Please review:
> 
> webrev: http://cr.openjdk.java.net/~acorn/8020489/webrev/
> http://bugs.sun.com/view_bug.do?bug_id=8020489
> 
> tests:
> jck test in bug report
> defmeth tests (no new failures)
> vm.quick.testlist in progress
> jprt in progress
> 
> thanks,
> Karen
> 
> 
> 
> 
> 
> -- 
> - Keith McGuigan <keith.mcguigan at alumni.unh.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130827/636c8aa7/attachment.html 

From coleen.phillimore at oracle.com  Tue Aug 27 13:05:07 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 27 Aug 2013 16:05:07 -0400
Subject: RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV in
	Unsafe_SetByte+0x35
In-Reply-To: <521D005D.4050004@oracle.com>
References: <521BFA78.9070908@oracle.com> <521CD14D.5040809@oracle.com>
	<5CDAD4D1-5A6C-45EC-AAF3-4CB09FD76344@oracle.com>
	<521D005D.4050004@oracle.com>
Message-ID: <521D0673.6070106@oracle.com>


On 08/27/2013 03:39 PM, Lois Foltan wrote:
>
> On 8/27/2013 1:29 PM, Christian Thalinger wrote:
>> On Aug 27, 2013, at 9:18 AM, Lois Foltan <lois.foltan at oracle.com> wrote:
>>
>>> Please review the following fix:
>>>     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/
>>>
>>> Bug:
>>>     bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>>
>>> Summary of fix:
>>>
>>> The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ 
>>> compiler, exhibited a compiler optimization issue when 
>>> prims/unsafe.cpp was compiled at the default -Os level. As a work 
>>> around fix, knock the optimization level down down to -O0.
>> Why are we lowering to -O0 when you state in the bug report that -O1 
>> also works?  What is the code that breaks?
>>
>> -- Chris
> Hi Chris,
> The convention within make/bsd/makefiles/gcc.make indicated that 
> historically files that exhibited C++ compiler optimization issues 
> were knocked down to /NOOPT or -O0.  I did also check with Coleen to 
> make sure that prims/unsafe.cpp was not a performance critical file. 

So my advice was that it wasn't performance critical - because it's 
mostly calls from Java.  Except for maybe the anonymous class 
functions.  If you disagree, let us know.

Coleen

> -O1 does add some optimizations on top of -O0 but not inlining.  I 
> will recheck testing with -O1 to confirm and change unsafe.cpp's 
> optimization level to -O1 if testing yields good results.
>
> I suspect the optimization problem is in unsafe.cpp's definition of 
> Unsafe_GetNativeByte.  I had left off tracking it at that level and 
> certainly will not close the JDK bug until I can narrow in further and 
> hopefully report to the clang compiler team.
>
> Thanks,
> Lois
>>> Tests:
>>>     MacOS: built fastdebug & product images using clang++ (ran JTREG 
>>> & vm.quick.testlist)
>>>                    built using llvm-g++ to verify prims/unsafe.cpp 
>>> remained compiled at -Os
>>>
>>> Thank you,
>>> Lois
>>>
>>>
>


From coleen.phillimore at oracle.com  Tue Aug 27 13:08:57 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 27 Aug 2013 16:08:57 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521D0131.1040201@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
	<521C9F11.5010809@oracle.com>
	<B701E9CB-624F-4CF4-9C40-B2A717254400@oracle.com>
	<521D0131.1040201@oracle.com>
Message-ID: <521D0759.4000104@oracle.com>


On 08/27/2013 03:42 PM, Lois Foltan wrote:
>
> On 8/27/2013 1:49 PM, Christian Thalinger wrote:
>>
>> On Aug 27, 2013, at 5:44 AM, Lois Foltan <lois.foltan at oracle.com 
>> <mailto:lois.foltan at oracle.com>> wrote:
>>
>>>
>>> On 8/27/2013 7:31 AM, David Holmes wrote:
>>>> On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
>>>>> On 2013-08-27 04:41, David Holmes wrote:
>>>>>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>>>>>> Please review the following fix:
>>>>>>>
>>>>>>> Internal webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>>>>>
>>>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file 
>>>>>>> produced &
>>>>>>>           runtime/6878713/Test6878713.sh fails on mac
>>>>>>>
>>>>>>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>>>>
>>>>>>> Summary of fix:
>>>>>>>      On MacOS, currently Hotspot is built specifying the 
>>>>>>> -fcheck-new
>>>>>>> command line option to the llvm-g++ compiler.
>>>>>>>      The -fcheck-new option directs the compiler to "check that the
>>>>>>> pointer returned by |operator new| is non-null
>>>>>>>       before attempting to modify the storage allocated."  The 
>>>>>>> clang++
>>>>>>> compiler does not support the
>>>>>>>       -fcheck-new option.  To obtain similiar functionality when
>>>>>>> building Hotspot with clang++, empty exception
>>>>>>>       throw() specifications must be added to all user-defined 
>>>>>>> operator
>>>>>>> new()'s.
>>>>>>
>>>>>> We just spotted something related in the PPC64 port and were 
>>>>>> going the
>>>>>> other way or removing these "spurious" throw() declarations.
>>>>>>
>>>>>> But this seems really ugly - is there really a need to specialize 
>>>>>> this
>>>>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
>>>>>> honour the nothrow() semantics?
>>>>>>
>>>>>> That said I thought we already handled this using the "const
>>>>>> std::nothrow_t&  nothrow_constant" where needed? Our other 
>>>>>> operator new
>>>>>> implementations shouldn't return NULL but will abort.
>>>>>>
>>>>>> So why do we need -fcheck-new or this empty throw() ?
>>>>>
>>>>> I guess that if the C++ compiler knows that operator new() will 
>>>>> throw an
>>>>> exception if an allocation fails then it doesn't need to emit code to
>>>>> explicitly avoid calling the constructor.
>>>>
>>>> Yes that is what happens, but why do _we_ need it when ...
>>>>
>>>>> If we declare operator new() with an empty throw() we will also 
>>>>> inform
>>>>> the compiler that new can't throw an exception and therefore the
>>>>> compiler needs to explicitly handle failed allocations.
>>>>
>>>> ... we have two kinds of operator new implementations (or at least 
>>>> we _should_ only have two kinds):
>>>>
>>>> 1. Will abort on OOM (either ResourceArea exhaustion or Stack 
>>>> exhaustion) and so never returns NULL
>>>> 2. Can return NULL and uses std::nothrow to indicate that
>>>>
>>>> So we should not need this if the nothrow is acting as I think it 
>>>> should. Have we missed places where nothrow is needed? Do we have 
>>>> errant operator new definitions unrelated to the allocation base 
>>>> classes?
>>> Hi David,
>>>
>>> I think there may be some confusion about what std::nothrow_t is 
>>> actually doing.  It provides a mechanism to overload operator new & 
>>> delete in order to direct the compiler to prefer a function 
>>> definition that also should contain an empty "throw()" 
>>> specification.  Take for example the standard definition of the 
>>> global ::operator new().  It actually looks like:
>>>
>>>   * void * operator new
>>>     <x-msg://14159/a00960.html#a1414bcdb34c39ce82fc84bc8d5287966>
>>>     (std::size_t) throw (std::bad_alloc)
>>>   * void * operator new
>>>     <x-msg://14159/a00960.html#a940b606c7824b4d5dd121199c277d629>
>>>     (std::size_t, const std::nothrow_t &) throw ()
>>>
>>> When the std::nothrow_t parameter is passed to the global ::operator 
>>> new() the invoked function is the one that also contains an empty 
>>> throw() specification.  It is due to this empty throw() 
>>> specification that directs or triggers the C++ compiler to generate 
>>> the detection of NULL constructor prologue.   Specifying only the 
>>> std::nothrow_t parameter to a class member user-defined ::operator 
>>> new() does not indicate to a C++ compiler that the function does not 
>>> throw an exception.  According to the c++98 standard, a function 
>>> that will throw no exceptions should be delcared with an empty 
>>> "throw()" list specification.  When first experimenting with a fix, 
>>> I did just try to overload Hotspot's user-defined operator new() 
>>> with the std:nothrow_t parameter.  As expected, the mere presence of 
>>> this parameter did not trigger the clang++ compiler to generate NULL 
>>> detection constructor prologue code. Unfortunately, probably due to 
>>> legacy code, some C++ compilers behave differently.  For example, I 
>>> did confirm with Solaris C++ development, the Solaris C++ by default 
>>> always generates constructor prologue code that detects NULL for 
>>> class member user-defined operator new() even in a throw situation.  
>>> G++ provides the -fcheck-new command line option.  It is due to 
>>> these differences of behavior or Hotspot's build specification of 
>>> -fcheck-new that has led us to believe that std::nothrow_t was 
>>> providing something that it is not.
>>>
>>> That said, I would also prefer what you propose, deciding on two 
>>> kinds of operator new()'s that can be defined.  I did examine all of 
>>> the user-defined operator new()'s within the code and I determined 
>>> that only a very small number possibly could not return NULL.  Given 
>>> this, factored in with the historical reliance on -fcheck-new for 
>>> the g++ compilers, I decided the safe route for JDK 8 was to 
>>> introduce the NOEXCEPT macro.
>>
>> Why can't we use throw() with all compilers?  Just because we are 
>> using -fcheck-new for GCC?
> Hi Chris,
>
> Yes certainly that would be preferable to the NOEXCEPT macro.  I also 
> believe most modern C++ compilers support the c++98 standard at this 
> point and would handle the empty throw() specification correctly.  
> However, after discussing with Coleen, it was thought that in order to 
> limit the scope of this change for JDK 8 introducing the NOEXCEPT 
> macro was again the safer route.
>


The NOEXCEPT macro isn't less code changes and the empty throw() would 
probably work, but there's a new c++11 keyword "noexcept" that we might 
need in the future for this behavior.   So the macro enables changing it 
to that for compilers that support it.  That was our thinking at least.

Coleen

> Thanks,
> Lois
>
>>
>> -- Chris
>>
>>>
>>> Lois
>>>>
>>>> David
>>>> -----
>>>>
>>>>> The g++ man page states:
>>>>>
>>>>>         -fcheck-new
>>>>>             Check that the pointer returned by "operator new" is
>>>>> non-null before attempting to modify the storage allocated.  This 
>>>>> check
>>>>> is normally unnecessary because the C++ standard specifies that
>>>>>             "operator new" will only return 0 if it is declared 
>>>>> throw(),
>>>>> in which case the compiler will always check the return value even
>>>>> without this option.  In all other cases, when "operator new"
>>>>>             has a non-empty exception specification, memory 
>>>>> exhaustion
>>>>> is signalled by throwing "std::bad_alloc".  See also new (nothrow).
>>>>>
>>>>> /Mikael
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Tests:
>>>>>>>
>>>>>>>       Solaris: built fastdebug & product images
>>>>>>>       Linux: built fastdebug & product images
>>>>>>>       MacOS:  built fastdebug & product images using llvm-g++ - ran
>>>>>>> JTREG
>>>>>>>                      built fastdebug & product images using 
>>>>>>> clang++ -
>>>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>>>>>       Windows:  built fastdebug & product images with VS2010
>>>>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130827/2a37e602/attachment-0001.html 

From ioi.lam at oracle.com  Tue Aug 27 14:21:41 2013
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Tue, 27 Aug 2013 21:21:41 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets
Message-ID: <20130827212149.AD3C348BF8@hg.openjdk.java.net>

Changeset: f462e61bce87
Author:    iklam
Date:      2013-08-26 21:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f462e61bce87

8020622: create.bat on Windows failed to create project file for Visual Studio 2012
Summary: Treat VS2012 the same as VS2010.
Reviewed-by: dcubed, kamg, minqi

! make/windows/create.bat
! make/windows/makefiles/rules.make

Changeset: 35471dcba316
Author:    iklam
Date:      2013-08-27 03:35 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/35471dcba316

Merge


Changeset: c26d57fa08aa
Author:    iklam
Date:      2013-08-27 16:02 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c26d57fa08aa

Merge



From jiangli.zhou at oracle.com  Tue Aug 27 17:31:05 2013
From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com)
Date: Wed, 28 Aug 2013 00:31:05 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 8020829: JT_HS: 2 runtime NMT tests fail
	on platforms if NMT detail is not supported
Message-ID: <20130828003109.1DA7D48BFD@hg.openjdk.java.net>

Changeset: 5fd8e2fbafd4
Author:    cjplummer
Date:      2013-08-23 12:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5fd8e2fbafd4

8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported
Summary: Make tests query a new WhiteBox API to see if NMT detail is supported, and behave properly if it is not supported.
Reviewed-by: dholmes, coleenp

! src/share/vm/prims/whitebox.cpp
! test/runtime/NMT/ThreadedVirtualAllocTestType.java
! test/runtime/NMT/VirtualAllocTestType.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java


From david.holmes at oracle.com  Tue Aug 27 17:46:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 28 Aug 2013 10:46:38 +1000
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521C9F11.5010809@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
	<521C9F11.5010809@oracle.com>
Message-ID: <521D486E.8090207@oracle.com>

Hi Lois,

Thanks for the detailed explanation. It is frustrating that we keep 
having to revisit these allocation routines.

However it still seems to me that we don't need NO_EXCEPT on most of our 
operator new definitions because they will never return NULL. This is 
trivially so for things like:

  void* StackObj::operator new(size_t size)     NOEXCEPT { 
ShouldNotCallThis(); return 0; }
void* _ValueObj::operator new(size_t size)    NOEXCEPT { 
ShouldNotCallThis(); return 0; }

but also for anything that invokes vm_exit_out_of_memory directly or 
indirectly.

David
-----

On 27/08/2013 10:44 PM, Lois Foltan wrote:
>
> On 8/27/2013 7:31 AM, David Holmes wrote:
>> On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
>>> On 2013-08-27 04:41, David Holmes wrote:
>>>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>>>> Please review the following fix:
>>>>>
>>>>> Internal webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>>>
>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file
>>>>> produced &
>>>>>           runtime/6878713/Test6878713.sh fails on mac
>>>>>
>>>>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>>
>>>>> Summary of fix:
>>>>>      On MacOS, currently Hotspot is built specifying the -fcheck-new
>>>>> command line option to the llvm-g++ compiler.
>>>>>      The -fcheck-new option directs the compiler to "check that the
>>>>> pointer returned by |operator new| is non-null
>>>>>       before attempting to modify the storage allocated." The clang++
>>>>> compiler does not support the
>>>>>       -fcheck-new option.  To obtain similiar functionality when
>>>>> building Hotspot with clang++, empty exception
>>>>>       throw() specifications must be added to all user-defined
>>>>> operator
>>>>> new()'s.
>>>>
>>>> We just spotted something related in the PPC64 port and were going the
>>>> other way or removing these "spurious" throw() declarations.
>>>>
>>>> But this seems really ugly - is there really a need to specialize this
>>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
>>>> honour the nothrow() semantics?
>>>>
>>>> That said I thought we already handled this using the "const
>>>> std::nothrow_t&  nothrow_constant" where needed? Our other operator new
>>>> implementations shouldn't return NULL but will abort.
>>>>
>>>> So why do we need -fcheck-new or this empty throw() ?
>>>
>>> I guess that if the C++ compiler knows that operator new() will throw an
>>> exception if an allocation fails then it doesn't need to emit code to
>>> explicitly avoid calling the constructor.
>>
>> Yes that is what happens, but why do _we_ need it when ...
>>
>>> If we declare operator new() with an empty throw() we will also inform
>>> the compiler that new can't throw an exception and therefore the
>>> compiler needs to explicitly handle failed allocations.
>>
>> ... we have two kinds of operator new implementations (or at least we
>> _should_ only have two kinds):
>>
>> 1. Will abort on OOM (either ResourceArea exhaustion or Stack
>> exhaustion) and so never returns NULL
>> 2. Can return NULL and uses std::nothrow to indicate that
>>
>> So we should not need this if the nothrow is acting as I think it
>> should. Have we missed places where nothrow is needed? Do we have
>> errant operator new definitions unrelated to the allocation base classes?
> Hi David,
>
> I think there may be some confusion about what std::nothrow_t is
> actually doing.  It provides a mechanism to overload operator new &
> delete in order to direct the compiler to prefer a function definition
> that also should contain an empty "throw()" specification.  Take for
> example the standard definition of the global ::operator new().  It
> actually looks like:
>
>   * void * operator new <a00960.html#a1414bcdb34c39ce82fc84bc8d5287966>
>     (std::size_t) throw (std::bad_alloc)
>   * void * operator new <a00960.html#a940b606c7824b4d5dd121199c277d629>
>     (std::size_t, const std::nothrow_t &) throw ()
>
> When the std::nothrow_t parameter is passed to the global ::operator
> new() the invoked function is the one that also contains an empty
> throw() specification.  It is due to this empty throw() specification
> that directs or triggers the C++ compiler to generate the detection of
> NULL constructor prologue.   Specifying only the std::nothrow_t
> parameter to a class member user-defined ::operator new() does not
> indicate to a C++ compiler that the function does not throw an
> exception.  According to the c++98 standard, a function that will throw
> no exceptions should be delcared with an empty "throw()" list
> specification.  When first experimenting with a fix, I did just try to
> overload Hotspot's user-defined operator new() with the std:nothrow_t
> parameter.  As expected, the mere presence of this parameter did not
> trigger the clang++ compiler to generate NULL detection constructor
> prologue code.  Unfortunately, probably due to legacy code, some C++
> compilers behave differently.  For example, I did confirm with Solaris
> C++ development, the Solaris C++ by default always generates constructor
> prologue code that detects NULL for class member user-defined operator
> new() even in a throw situation. G++ provides the -fcheck-new command
> line option.  It is due to these differences of behavior or Hotspot's
> build specification of -fcheck-new that has led us to believe that
> std::nothrow_t was providing something that it is not.
>
> That said, I would also prefer what you propose, deciding on two kinds
> of operator new()'s that can be defined.  I did examine all of the
> user-defined operator new()'s within the code and I determined that only
> a very small number possibly could not return NULL.  Given this,
> factored in with the historical reliance on -fcheck-new for the g++
> compilers, I decided the safe route for JDK 8 was to introduce the
> NOEXCEPT macro.
>
> Lois
>>
>> David
>> -----
>>
>>> The g++ man page states:
>>>
>>>         -fcheck-new
>>>             Check that the pointer returned by "operator new" is
>>> non-null before attempting to modify the storage allocated. This check
>>> is normally unnecessary because the C++ standard specifies that
>>>             "operator new" will only return 0 if it is declared throw(),
>>> in which case the compiler will always check the return value even
>>> without this option.  In all other cases, when "operator new"
>>>             has a non-empty exception specification, memory exhaustion
>>> is signalled by throwing "std::bad_alloc".  See also new (nothrow).
>>>
>>> /Mikael
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Tests:
>>>>>
>>>>>       Solaris: built fastdebug & product images
>>>>>       Linux: built fastdebug & product images
>>>>>       MacOS:  built fastdebug & product images using llvm-g++ - ran
>>>>> JTREG
>>>>>                      built fastdebug & product images using clang++ -
>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>>>       Windows:  built fastdebug & product images with VS2010
>>>>>
>

From christian.thalinger at oracle.com  Tue Aug 27 18:15:28 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 27 Aug 2013 18:15:28 -0700
Subject: RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV in
	Unsafe_SetByte+0x35
In-Reply-To: <521D0673.6070106@oracle.com>
References: <521BFA78.9070908@oracle.com> <521CD14D.5040809@oracle.com>
	<5CDAD4D1-5A6C-45EC-AAF3-4CB09FD76344@oracle.com>
	<521D005D.4050004@oracle.com> <521D0673.6070106@oracle.com>
Message-ID: <E2EB7082-EC20-4635-B15A-BDF9340C7494@oracle.com>


On Aug 27, 2013, at 1:05 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> 
> On 08/27/2013 03:39 PM, Lois Foltan wrote:
>> 
>> On 8/27/2013 1:29 PM, Christian Thalinger wrote:
>>> On Aug 27, 2013, at 9:18 AM, Lois Foltan <lois.foltan at oracle.com> wrote:
>>> 
>>>> Please review the following fix:
>>>>    open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/
>>>> 
>>>> Bug:
>>>>    bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>>> 
>>>> Summary of fix:
>>>> 
>>>> The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ compiler, exhibited a compiler optimization issue when prims/unsafe.cpp was compiled at the default -Os level. As a work around fix, knock the optimization level down down to -O0.
>>> Why are we lowering to -O0 when you state in the bug report that -O1 also works?  What is the code that breaks?
>>> 
>>> -- Chris
>> Hi Chris,
>> The convention within make/bsd/makefiles/gcc.make indicated that historically files that exhibited C++ compiler optimization issues were knocked down to /NOOPT or -O0.  I did also check with Coleen to make sure that prims/unsafe.cpp was not a performance critical file. 
> 
> So my advice was that it wasn't performance critical - because it's mostly calls from Java.  Except for maybe the anonymous class functions.  If you disagree, let us know.

I agree.  Most of the (performance critical) Unsafe methods are intrinsified anyway but why waste computing cycles and more importantly bytes (in object size) if we don't have to.

-- Chris

> 
> Coleen
> 
>> -O1 does add some optimizations on top of -O0 but not inlining.  I will recheck testing with -O1 to confirm and change unsafe.cpp's optimization level to -O1 if testing yields good results.
>> 
>> I suspect the optimization problem is in unsafe.cpp's definition of Unsafe_GetNativeByte.  I had left off tracking it at that level and certainly will not close the JDK bug until I can narrow in further and hopefully report to the clang compiler team.
>> 
>> Thanks,
>> Lois
>>>> Tests:
>>>>    MacOS: built fastdebug & product images using clang++ (ran JTREG & vm.quick.testlist)
>>>>                   built using llvm-g++ to verify prims/unsafe.cpp remained compiled at -Os
>>>> 
>>>> Thank you,
>>>> Lois
>>>> 
>>>> 
>> 
> 


From yumin.qi at oracle.com  Tue Aug 27 20:26:55 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 27 Aug 2013 20:26:55 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <op.w2hjzntytc8ri4@eckenfels02.seeburger.de>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>
	<521CDE52.2030407@oracle.com>
	<op.w2hjzntytc8ri4@eckenfels02.seeburger.de>
Message-ID: <521D6DFF.7050706@oracle.com>

Hi, Bernd

On 8/27/2013 10:27 AM, Bernd Eckenfels wrote:
> Hello,
>
> no matter what you decide (for example configurable pattern like J9 is 
> doing it) please add enough header informatiomn to the logfile that it 
> answers common gc diagnostic questions (version, command line 
> settings, ram/swap size) and the start wallclock of the segment (for 
> calculating abolute times without using the datestamp option).
>
The log file will log what ever the gc logging is currently writing to 
the file. In this fix, there is no changes to such information. The only 
additional information added to the log file is that at rotation moment, 
file name and create time information is logged to head of file for new 
file, like:

2013-08-27 12:04:13 GC log file created test-pid27685-2013-08-27_12-02-15.1
117.334: [GC (Allocation Failure) 117.334: [ParNew: 17305K->2K(19648K), 
0.0040920 secs] 98474K->81171K(182528K), 0.0044070 secs] [Times: 
user=0.01 sys=0.00, real=0.01 secs]
117.342: [GC (Allocation Failure) 117.342: [ParNew: 17305K->2K(19648K), 
0.0038690 secs] 98474K->81171K(182528K), 0.0041920 secs] [Times: 
user=0.01 sys=0.00, real=0.00 secs]

You can see that at the beginning, wall clock of the file create time 
and file name are logged.

For tail:

117.318: [GC (Allocation Failure) 117.318: [ParNew: 17305K->2K(19648K), 
0.0038870 secs] 98474K->81171K(182528K), 0.0042070 secs] [Times: 
user=0.01 sys=0.00, real=0.00 secs]
117.326: [GC (Allocation Failure) 117.326: [ParNew: 17305K->2K(19648K), 
0.0040940 secs] 98474K->81171K(182528K), 0.0044230 secs] [Times: 
user=0.01 sys=0.00, real=0.01 secs]
2013-08-27 12:04:13 GC log file has reached the maximum size. Saved as 
test-pid27685-2013-08-27_12-02-15.0

This is previous log file.

Thanks
Yumin

> Greetings
> Bernd


From yumin.qi at oracle.com  Tue Aug 27 20:32:56 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 27 Aug 2013 20:32:56 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521CDE52.2030407@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>
	<521CDE52.2030407@oracle.com>
Message-ID: <521D6F68.6050000@oracle.com>

Hi,

  Based on the discussion, I updated the webrev, and in this version
1) deleted unused rotatingFileStream  constructor, which keep code shorter.
2) removed reformat_filename in previous version.
3) still keep original design, that if no rotation, just use file name 
given by -Xloggc:<filename>.

Others are basically same.

Please take a look and comment.

http://cr.openjdk.java.net/~minqi/7164841/webrev02 
<http://cr.openjdk.java.net/%7Eminqi/7164841/webrev02>

Thanks
Yumin

On 8/27/2013 10:13 AM, Tao Mao wrote:
>
>
> On 8/27/13 1:01 AM, Bengt Rutisson wrote:
>>
>> Yumin,
>>
>> On 8/26/13 7:01 PM, Yumin Qi wrote:
>>> Bengt,
>>>
>>>   Thanks for your comments.
>>>   Yes, as you said, the purpose of rotating logs is primarily 
>>> targeted for saving disk space. This bug is supplying customers 
>>> another option to prevent the previous gc logs from removed by 
>>> restart app without making copy. Now with this pid and time stamp 
>>> included in file name,  we have more options for users. It is up to 
>>> user to make decision to or not to keep the logs. We cannot handle 
>>> all the requests in JVM, but we can offer the choices for users I 
>>> think. Any way, with either the previous rotating version, or the 
>>> one I am working, the logs will not grow constantly without limit to 
>>> blow storage out as long as users give enough attention.
>>>
>>>   My concern is for no log rotation, should we still use time stamp 
>>> in file name? I have one version for this, I hope get more comments 
>>> for that.
>>
>> Sorry if I wasn't clear before. I am not worried about the case when 
>> log rotation is turned on. What I was worried about was the case 
>> where a user is not using log rotation but is still piping the GC 
>> output to a file. That file will be overwritten every time the VM is 
>> restarted. If we add time stamps to the file name for this case then 
>> the file will not be overwritten. I think that is a bit of a scary 
>> change. That's all.
>
> If you are worried about the case where a user is not using log 
> rotation but creating a new file for each restart, you should be 
> almost equivalently worried about the case where a user is using log 
> rotation and having many rotated logs created which are different for 
> each VM restart. Basically, we are creating even more files over time, 
> which falls into your concern.
>
> At this point, I'm fine with either choice for they have pros and 
> cons. If we always append date and time to log file names, customers 
> may say "the logs are 'eating' my disk"; if you don't do that, the 
> customers would still complain the log is overwritten after a restart 
> (I saw these kinds of CR's twice).
>
> Thanks.
> Tao
>
>>
>> Bengt
>>
>>>
>>>   More comments are appreciated by sending to more wide audience, 
>>> especially sustaining, they have more experience with customer request.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>>
>>> On 8/26/2013 4:47 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi Yumin and Tao,
>>>>
>>>> I have not reviewed the code change but I have a comment inlined 
>>>> below.
>>>>
>>>> On 8/24/13 1:05 AM, Yumin Qi wrote:
>>>>> Tao,
>>>>>
>>>>>   Thanks for your review.
>>>>>
>>>>> On 8/23/2013 3:33 PM, Tao Mao wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I reviewed most of the code and test-ran a build from it. It's a 
>>>>>> very cool and important improvement.
>>>>>>
>>>>>> Thank you for putting together these on our wishlist for long.
>>>>>>
>>>>>> Below are some comments.
>>>>>>
>>>>>> 1. src/share/vm/runtime/arguments.cpp
>>>>>>
>>>>>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>>>>>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>>>>>
>>>>>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>>>>>
>>>>>> I worked on a problem of enabling gc log limit over 2G 
>>>>>> (JDK-7122222). So it seems that customers sometimes want gc logs 
>>>>>> to be very large.
>>>>>>
>>>>> Sure, will add.
>>>>>> 2. src/share/vm/runtime/arguments.hpp
>>>>>>
>>>>>> (1) with the current changeset, we only append date&time to 
>>>>>> file_name w/ +UseGCLogFileRotation; if not, we won't have 
>>>>>> date&time info.
>>>>>>
>>>>>> I think it would be useful to let both cases (w/ and w/o 
>>>>>> UseGCLogFileRotation) have date&time in order to solve the 
>>>>>> overwritten problem (e.g. JDK-8020667). In fact, having that, we 
>>>>>> actually solve JDK-8020667.
>>>>>>
>>>>>> If you want to have that, basically you need to work on the 
>>>>>> FileStream constructor methods fileStream().
>>>>>>
>>>>> I can change that, if no objection from others. This also will 
>>>>> simplify the setting of file name here.
>>>>
>>>> I think appending a timestamp to the log file name is a nice idea, 
>>>> but I think it is also a bit scary. There are users who restart 
>>>> their applications regularly. With the suggested idea such users 
>>>> will now risk filling up their disk space with log files. I imagine 
>>>> that that will not be appreciated by everyone. Such a change should 
>>>> probably be discussed more thoroughly than just in a review request.
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>
>>>>>
>>>>>> (2) Would it be better to rename method name reformat_filename() 
>>>>>> to extend_filename()?
>>>>>>
>>>>>> (3) Typos and suggestion
>>>>>> 537 // rotate file in names filename.0, filename.1, ..., 
>>>>>> filename.<NumberOfGCLogFiles - 1>
>>>>>> *=> extended_filename.0*
>>>>>>
>>>>>> 538 // filename contains pid and time when the fist file created. 
>>>>>> The current filename is
>>>>>> *=> *the*first *file created.
>>>>>>
>>>>>> 539 // gc_log_file_name + pid<pid> + 
>>>>>> YYYY-MM-DD_HH-MM-SS.<i>.current, where i is current
>>>>>> 540 // rotation file number. After it reaches max file size, the 
>>>>>> file will be saved and
>>>>>> 541 // renamed with .current removed from its tail.
>>>>>>
>>>>> Will change that.
>>>>>> 3. For your point 5), I don't quite get it. In my test-run, I 
>>>>>> tried to change file permission to unreadable and unwritable, but 
>>>>>> VM would later change the permission back anyway.
>>>>>>
>>>>>> So could you bring up some use cases of that functionality to 
>>>>>> give more details?
>>>>>>
>>>>> Changing file permission will not stop the file create, in this 
>>>>> rotation, the file opened/saved/removed/renamed -> then repeat. 
>>>>> What I have done is change the while directory to read only, then 
>>>>> the create failed so rotation stopped.
>>>>>
>>>>>> 4. Will you write jtreg tests for this functionality? It looks 
>>>>>> possible to write some tests, at least checking the format of log 
>>>>>> names.
>>>>>>
>>>>> Good suggestion, I will add one.
>>>>>
>>>>>> Thanks.
>>>>>> Tao
>>>>>>
>>>>>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>>>>>> Could I get  a GC staff review the change? Need more reviewers 
>>>>>>> to push this in.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>>>>>> Hi, all
>>>>>>>>
>>>>>>>>   This is second version after feedback from first round.
>>>>>>>>   The changes are:
>>>>>>>>
>>>>>>>>   1) file name will be based on gc log file name 
>>>>>>>> (-Xloggc:filename), pid (process id) and time when the first 
>>>>>>>> rotation file created:
>>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>>>>>   2) If rotate in same file, file name is as in 1), if rotate 
>>>>>>>> in multiple files, .<i> will append to above file name.
>>>>>>>>   3) every time file rotated, file name and time when file 
>>>>>>>> created will be logged to head/tail, this is same as first 
>>>>>>>> version.
>>>>>>>>   4) current file has name 
>>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>>>>>        This is similar to first version.
>>>>>>>>        By adapting such name format we will never loss logs in 
>>>>>>>> case apps stops and restart, the log files will not be 
>>>>>>>> overwritten since time stamp in file names.
>>>>>>>>    5) If open file failed, turn off gc log rotation.
>>>>>>>>         If due to some reason, file operation failed (such as 
>>>>>>>> permission changed etc), with log file opened, logging still 
>>>>>>>> works, but at
>>>>>>>>         saving and renaming, the file operation will fail, this 
>>>>>>>> will lead not all files saved.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>>>>>
>>>>>>>>      Tested with jtreg, JPRT.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>
>>>>>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>   Can I have your review for this small changes?
>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>>>>>
>>>>>>>>>    This is for a enhancement to add head/tail message to the 
>>>>>>>>> logging files to assist reading GC output.
>>>>>>>>>    1. modified prompt message if invalid arguments used for 
>>>>>>>>> log rotating;
>>>>>>>>>    2. add time and file name message to log file head/tail.
>>>>>>>>>    3. for easily identify which log file is current, use file 
>>>>>>>>> name like <filename>.n.current, after it reaches maximum size, 
>>>>>>>>> rename it to <filename>.n
>>>>>>>>>         On Windows, there is no F_OK (existing test) 
>>>>>>>>> definition, F_OK is defined as "0" and for _access of VC++, it 
>>>>>>>>> just describes:
>>>>>>>>>
>>>>>>>>> modevalue
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Checks file for
>>>>>>>>>
>>>>>>>>> 00
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Existence only
>>>>>>>>>
>>>>>>>>> 02
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Write-only
>>>>>>>>>
>>>>>>>>> 04
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Read-only
>>>>>>>>>
>>>>>>>>> 06
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Read and write
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>>>>>> The definition are consistent with unistd.h.
>>>>>>>>>
>>>>>>>>>     Test: JPRT and jtreg.
>>>>>>>>>
>>>>>>>>>    Thanks
>>>>>>>>>    Yumin
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>


From david.holmes at oracle.com  Tue Aug 27 21:07:01 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Wed, 28 Aug 2013 04:07:01 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 8006164: [TESTBUG] compact profile
	hotspot test issues
Message-ID: <20130828040708.26CA448C05@hg.openjdk.java.net>

Changeset: 7aa0c1fb6fdb
Author:    dholmes
Date:      2013-08-27 22:05 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7aa0c1fb6fdb

8006164: [TESTBUG] compact profile hotspot test issues
Summary: Define profile-based test groups.
Reviewed-by: dcubed, mchung

! test/TEST.ROOT
+ test/TEST.groups


From karen.kinnear at oracle.com  Wed Aug 28 05:10:35 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 28 Aug 2013 08:10:35 -0400
Subject: XS RFR: 8020489: Lambda: VM crash when non-existent interface
	method called by invokespecial
In-Reply-To: <521CF769.3040103@oracle.com>
References: <22B47FFD-91D6-4E6D-A946-11EC773A87FC@oracle.com>
	<9ABFECFE-FB00-40A8-839D-E67A298AFCA1@oracle.com>
	<9E0D4E5C-FEE1-4384-8998-A0A5D70326E2@oracle.com>
	<521CF769.3040103@oracle.com>
Message-ID: <79BC1D36-07A4-4F35-9DC4-FD29A754C8A4@oracle.com>

Many thanks for the quick review!

Karen

On Aug 27, 2013, at 3:00 PM, Coleen Phillimore wrote:

> 
> Looks good.
> Coleen
> 
> On 08/27/2013 02:25 PM, Karen Kinnear wrote:
>> Please review:
>> 
>> webrev: http://cr.openjdk.java.net/~acorn/8020489/webrev/
>> http://bugs.sun.com/view_bug.do?bug_id=8020489
>> 
>> tests:
>> jck test in bug report
>> defmeth tests (no new failures)
>> vm.quick.testlist in progress
>> jprt in progress
>> 
>> thanks,
>> Karen
>> 
>> 
> 


From bernd-2013 at eckenfels.net  Tue Aug 27 10:27:10 2013
From: bernd-2013 at eckenfels.net (Bernd Eckenfels)
Date: Tue, 27 Aug 2013 19:27:10 +0200
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521CDE52.2030407@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>
	<521CDE52.2030407@oracle.com>
Message-ID: <op.w2hjzntytc8ri4@eckenfels02.seeburger.de>

Hello,

no matter what you decide (for example configurable pattern like J9 is  
doing it) please add enough header informatiomn to the logfile that it  
answers common gc diagnostic questions (version, command line settings,  
ram/swap size) and the start wallclock of the segment (for calculating  
abolute times without using the datestamp option).

Greetings
Bernd

From ss4766 at att.com  Wed Aug 28 04:13:07 2013
From: ss4766 at att.com (STIRLING, SCOTT)
Date: Wed, 28 Aug 2013 11:13:07 +0000
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521CDE52.2030407@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com>
	<521C5CC8.5060102@oracle.com>,<521CDE52.2030407@oracle.com>
Message-ID: <D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>

Append vs clobber: with or without rotation, -Xloggc always clobbers the last log. That's why people want a time stamp or pid in the gc file name, IMHO.

Alternatively, give an option to append when -Xloggc is enabled, vs default overwrite.

Kind regards,

Scott Stirling
AT&T, Boston

On Aug 27, 2013, at 1:14 PM, "Tao Mao" <tao.mao at oracle.com> wrote:

> 
> 
> On 8/27/13 1:01 AM, Bengt Rutisson wrote:
>> 
>> Yumin,
>> 
>> On 8/26/13 7:01 PM, Yumin Qi wrote:
>>> Bengt,
>>> 
>>>  Thanks for your comments.
>>>  Yes, as you said, the purpose of rotating logs is primarily targeted for saving disk space. This bug is supplying  customers another option to prevent the previous gc logs from removed by restart app without making copy. Now with this pid and time stamp included in file name,  we have more options for users. It is up to user to make decision to or not to keep the logs. We cannot handle all the requests in JVM, but we can offer the choices for users I think. Any way, with either the previous rotating version, or the one I am working, the logs will not grow constantly without limit to blow storage out as long as users give enough attention.
>>> 
>>>  My concern is for no log rotation, should we still use time stamp in file name? I have one version for this, I hope get more comments for that.
>> 
>> Sorry if I wasn't clear before. I am not worried about the case when log rotation is turned on. What I was worried about was the case where a user is not using log rotation but is still piping the GC output to a file. That file will be overwritten every time the VM is restarted. If we add time stamps to the file name for this case then the file will not be overwritten. I think that is a bit of a scary change. That's all.
> 
> If you are worried about the case where a user is not using log rotation but creating a new file for each restart, you should be almost equivalently worried about the case where a user is using log rotation and having many rotated logs created which are different for each VM restart. Basically, we are creating even more files over time, which falls into your concern.
> 
> At this point, I'm fine with either choice for they have pros and cons. If we always append date and time to log file names, customers may say "the logs are 'eating' my disk"; if you don't do that, the customers would still complain the log is overwritten after a restart (I saw these kinds of CR's twice).
> 
> Thanks.
> Tao
> 
>> 
>> Bengt
>> 
>>> 
>>>  More comments are appreciated by sending to more wide audience, especially sustaining, they have more experience with customer request.
>>> 
>>> Thanks
>>> Yumin
>>> 
>>> 
>>> 
>>> On 8/26/2013 4:47 AM, Bengt Rutisson wrote:
>>>> 
>>>> Hi Yumin and Tao,
>>>> 
>>>> I have not reviewed the code change but I have a comment inlined below.
>>>> 
>>>> On 8/24/13 1:05 AM, Yumin Qi wrote:
>>>>> Tao,
>>>>> 
>>>>>  Thanks for your review.
>>>>> 
>>>>> On 8/23/2013 3:33 PM, Tao Mao wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I reviewed most of the code and test-ran a build from it. It's a very cool and important improvement.
>>>>>> 
>>>>>> Thank you for putting together these on our wishlist for long.
>>>>>> 
>>>>>> Below are some comments.
>>>>>> 
>>>>>> 1. src/share/vm/runtime/arguments.cpp
>>>>>> 
>>>>>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>>>>>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>>>>> 
>>>>>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>>>>> 
>>>>>> I worked on a problem of enabling gc log limit over 2G (JDK-7122222). So it seems that customers sometimes want gc logs to be very large.
>>>>> Sure, will add.
>>>>>> 2. src/share/vm/runtime/arguments.hpp
>>>>>> 
>>>>>> (1) with the current changeset, we only append date&time to file_name w/ +UseGCLogFileRotation; if not, we won't have date&time info.
>>>>>> 
>>>>>> I think it would be useful to let both cases (w/ and w/o UseGCLogFileRotation) have date&time in order to solve the overwritten problem (e.g. JDK-8020667). In fact, having that, we actually solve JDK-8020667.
>>>>>> 
>>>>>> If you want to have that, basically you need to work on the FileStream constructor methods fileStream().
>>>>> I can change that, if no objection from others. This also will simplify the setting of file name here.
>>>> 
>>>> I think appending a timestamp to the log file name is a nice idea, but I think it is also a bit scary. There are users who restart their applications regularly. With the suggested idea such users will now risk filling up their disk space with log files. I imagine that that will not be appreciated by everyone. Such a change should probably be discussed more thoroughly than just in a review request.
>>>> 
>>>> Thanks,
>>>> Bengt
>>>> 
>>>> 
>>>>> 
>>>>>> (2) Would it be better to rename method name reformat_filename() to extend_filename()?
>>>>>> 
>>>>>> (3) Typos and suggestion
>>>>>> 537 // rotate file in names filename.0, filename.1, ..., filename.<NumberOfGCLogFiles - 1>
>>>>>> *=> extended_filename.0*
>>>>>> 
>>>>>> 538 // filename contains pid and time when the fist file created. The current filename is
>>>>>> *=> *the*first *file created.
>>>>>> 
>>>>>> 539 // gc_log_file_name + pid<pid> + YYYY-MM-DD_HH-MM-SS.<i>.current, where i is current
>>>>>> 540 // rotation file number. After it reaches max file size, the file will be saved and
>>>>>> 541 // renamed with .current removed from its tail.
>>>>> Will change that.
>>>>>> 3. For your point 5), I don't quite get it. In my test-run, I tried to change file permission to unreadable and unwritable, but VM would later change the permission back anyway.
>>>>>> 
>>>>>> So could you bring up some use cases of that functionality to give more details?
>>>>> Changing file permission will not stop the file create, in this rotation, the file opened/saved/removed/renamed -> then repeat. What I have done is change the while directory to read only, then the create failed so rotation stopped.
>>>>> 
>>>>>> 4. Will you write jtreg tests for this functionality? It looks possible to write some tests, at least checking the format of log names.
>>>>> Good suggestion, I will add one.
>>>>> 
>>>>>> Thanks.
>>>>>> Tao
>>>>>> 
>>>>>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>>>>>> Could I get  a GC staff review the change? Need more reviewers to push this in.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>> 
>>>>>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>>>>>> Hi, all
>>>>>>>> 
>>>>>>>>  This is second version after feedback from first round.
>>>>>>>>  The changes are:
>>>>>>>> 
>>>>>>>>  1) file name will be based on gc log file name (-Xloggc:filename), pid (process id) and time when the first rotation file created:
>>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>>>>>  2) If rotate in same file, file name is as in 1), if rotate in multiple files, .<i> will append to above file name.
>>>>>>>>  3) every time file rotated, file name and time when file created will be logged to head/tail, this is same as first version.
>>>>>>>>  4) current file has name <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>>>>>       This is similar to first version.
>>>>>>>>       By adapting such name format we will never loss logs in case apps stops and restart, the log files will not be overwritten since time stamp in file names.
>>>>>>>>   5) If open file failed, turn off gc log rotation.
>>>>>>>>        If due to some reason, file operation failed (such as permission changed etc), with log file opened, logging still works, but at
>>>>>>>>        saving and renaming, the file operation will fail, this will lead not all files saved.
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>>>>> 
>>>>>>>>     Tested with jtreg, JPRT.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>> 
>>>>>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>>  Can I have your review for this small changes?
>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>>>>> 
>>>>>>>>>   This is for a enhancement to add head/tail message to the logging files to assist reading GC output.
>>>>>>>>>   1. modified prompt message if invalid arguments used for log rotating;
>>>>>>>>>   2. add time and file name message to log file head/tail.
>>>>>>>>>   3. for easily identify which log file is current, use file name like <filename>.n.current, after it reaches maximum size, rename it to <filename>.n
>>>>>>>>>        On Windows, there is no F_OK (existing test) definition, F_OK is defined as "0" and for _access of VC++, it just describes:
>>>>>>>>> 
>>>>>>>>> modevalue
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Checks file for
>>>>>>>>> 
>>>>>>>>> 00
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Existence only
>>>>>>>>> 
>>>>>>>>> 02
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Write-only
>>>>>>>>> 
>>>>>>>>> 04
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Read-only
>>>>>>>>> 
>>>>>>>>> 06
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Read and write
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>>>>>> The definition are consistent with unistd.h.
>>>>>>>>> 
>>>>>>>>>    Test: JPRT and jtreg.
>>>>>>>>> 
>>>>>>>>>   Thanks
>>>>>>>>>   Yumin
>> 

From ss4766 at att.com  Wed Aug 28 04:16:05 2013
From: ss4766 at att.com (STIRLING, SCOTT)
Date: Wed, 28 Aug 2013 11:16:05 +0000
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com>
	<521C5CC8.5060102@oracle.com>, <521CDE52.2030407@oracle.com>,
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>
Message-ID: <2250E242-628F-4687-9C99-3D061CCEC39F@att.com>

Always clobbers the last gc log *on JVM restart*, I should say. It's the JVM restart issue where there's no simple way via the JVM to just append to the last GC log if the file exists vs clobber it.

Scott

On Aug 28, 2013, at 7:13 AM, "STIRLING, SCOTT" <ss4766 at att.com> wrote:

> Append vs clobber: with or without rotation, -Xloggc always clobbers the last log. That's why people want a time stamp or pid in the gc file name, IMHO.
> 
> Alternatively, give an option to append when -Xloggc is enabled, vs default overwrite.
> 
> Kind regards,
> 
> Scott Stirling
> AT&T, Boston
> 
> On Aug 27, 2013, at 1:14 PM, "Tao Mao" <tao.mao at oracle.com> wrote:
> 
>> 
>> 
>> On 8/27/13 1:01 AM, Bengt Rutisson wrote:
>>> 
>>> Yumin,
>>> 
>>> On 8/26/13 7:01 PM, Yumin Qi wrote:
>>>> Bengt,
>>>> 
>>>> Thanks for your comments.
>>>> Yes, as you said, the purpose of rotating logs is primarily targeted for saving disk space. This bug is supplying  customers another option to prevent the previous gc logs from removed by restart app without making copy. Now with this pid and time stamp included in file name,  we have more options for users. It is up to user to make decision to or not to keep the logs. We cannot handle all the requests in JVM, but we can offer the choices for users I think. Any way, with either the previous rotating version, or the one I am working, the logs will not grow constantly without limit to blow storage out as long as users give enough attention.
>>>> 
>>>> My concern is for no log rotation, should we still use time stamp in file name? I have one version for this, I hope get more comments for that.
>>> 
>>> Sorry if I wasn't clear before. I am not worried about the case when log rotation is turned on. What I was worried about was the case where a user is not using log rotation but is still piping the GC output to a file. That file will be overwritten every time the VM is restarted. If we add time stamps to the file name for this case then the file will not be overwritten. I think that is a bit of a scary change. That's all.
>> 
>> If you are worried about the case where a user is not using log rotation but creating a new file for each restart, you should be almost equivalently worried about the case where a user is using log rotation and having many rotated logs created which are different for each VM restart. Basically, we are creating even more files over time, which falls into your concern.
>> 
>> At this point, I'm fine with either choice for they have pros and cons. If we always append date and time to log file names, customers may say "the logs are 'eating' my disk"; if you don't do that, the customers would still complain the log is overwritten after a restart (I saw these kinds of CR's twice).
>> 
>> Thanks.
>> Tao
>> 
>>> 
>>> Bengt
>>> 
>>>> 
>>>> More comments are appreciated by sending to more wide audience, especially sustaining, they have more experience with customer request.
>>>> 
>>>> Thanks
>>>> Yumin
>>>> 
>>>> 
>>>> 
>>>> On 8/26/2013 4:47 AM, Bengt Rutisson wrote:
>>>>> 
>>>>> Hi Yumin and Tao,
>>>>> 
>>>>> I have not reviewed the code change but I have a comment inlined below.
>>>>> 
>>>>> On 8/24/13 1:05 AM, Yumin Qi wrote:
>>>>>> Tao,
>>>>>> 
>>>>>> Thanks for your review.
>>>>>> 
>>>>>> On 8/23/2013 3:33 PM, Tao Mao wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I reviewed most of the code and test-ran a build from it. It's a very cool and important improvement.
>>>>>>> 
>>>>>>> Thank you for putting together these on our wishlist for long.
>>>>>>> 
>>>>>>> Below are some comments.
>>>>>>> 
>>>>>>> 1. src/share/vm/runtime/arguments.cpp
>>>>>>> 
>>>>>>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>>>>>>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>>>>>> 
>>>>>>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>>>>>> 
>>>>>>> I worked on a problem of enabling gc log limit over 2G (JDK-7122222). So it seems that customers sometimes want gc logs to be very large.
>>>>>> Sure, will add.
>>>>>>> 2. src/share/vm/runtime/arguments.hpp
>>>>>>> 
>>>>>>> (1) with the current changeset, we only append date&time to file_name w/ +UseGCLogFileRotation; if not, we won't have date&time info.
>>>>>>> 
>>>>>>> I think it would be useful to let both cases (w/ and w/o UseGCLogFileRotation) have date&time in order to solve the overwritten problem (e.g. JDK-8020667). In fact, having that, we actually solve JDK-8020667.
>>>>>>> 
>>>>>>> If you want to have that, basically you need to work on the FileStream constructor methods fileStream().
>>>>>> I can change that, if no objection from others. This also will simplify the setting of file name here.
>>>>> 
>>>>> I think appending a timestamp to the log file name is a nice idea, but I think it is also a bit scary. There are users who restart their applications regularly. With the suggested idea such users will now risk filling up their disk space with log files. I imagine that that will not be appreciated by everyone. Such a change should probably be discussed more thoroughly than just in a review request.
>>>>> 
>>>>> Thanks,
>>>>> Bengt
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> (2) Would it be better to rename method name reformat_filename() to extend_filename()?
>>>>>>> 
>>>>>>> (3) Typos and suggestion
>>>>>>> 537 // rotate file in names filename.0, filename.1, ..., filename.<NumberOfGCLogFiles - 1>
>>>>>>> *=> extended_filename.0*
>>>>>>> 
>>>>>>> 538 // filename contains pid and time when the fist file created. The current filename is
>>>>>>> *=> *the*first *file created.
>>>>>>> 
>>>>>>> 539 // gc_log_file_name + pid<pid> + YYYY-MM-DD_HH-MM-SS.<i>.current, where i is current
>>>>>>> 540 // rotation file number. After it reaches max file size, the file will be saved and
>>>>>>> 541 // renamed with .current removed from its tail.
>>>>>> Will change that.
>>>>>>> 3. For your point 5), I don't quite get it. In my test-run, I tried to change file permission to unreadable and unwritable, but VM would later change the permission back anyway.
>>>>>>> 
>>>>>>> So could you bring up some use cases of that functionality to give more details?
>>>>>> Changing file permission will not stop the file create, in this rotation, the file opened/saved/removed/renamed -> then repeat. What I have done is change the while directory to read only, then the create failed so rotation stopped.
>>>>>> 
>>>>>>> 4. Will you write jtreg tests for this functionality? It looks possible to write some tests, at least checking the format of log names.
>>>>>> Good suggestion, I will add one.
>>>>>> 
>>>>>>> Thanks.
>>>>>>> Tao
>>>>>>> 
>>>>>>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>>>>>>> Could I get  a GC staff review the change? Need more reviewers to push this in.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>> 
>>>>>>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>>>>>>> Hi, all
>>>>>>>>> 
>>>>>>>>> This is second version after feedback from first round.
>>>>>>>>> The changes are:
>>>>>>>>> 
>>>>>>>>> 1) file name will be based on gc log file name (-Xloggc:filename), pid (process id) and time when the first rotation file created:
>>>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>>>>>> 2) If rotate in same file, file name is as in 1), if rotate in multiple files, .<i> will append to above file name.
>>>>>>>>> 3) every time file rotated, file name and time when file created will be logged to head/tail, this is same as first version.
>>>>>>>>> 4) current file has name <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>>>>>>      This is similar to first version.
>>>>>>>>>      By adapting such name format we will never loss logs in case apps stops and restart, the log files will not be overwritten since time stamp in file names.
>>>>>>>>>  5) If open file failed, turn off gc log rotation.
>>>>>>>>>       If due to some reason, file operation failed (such as permission changed etc), with log file opened, logging still works, but at
>>>>>>>>>       saving and renaming, the file operation will fail, this will lead not all files saved.
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>>>>>> 
>>>>>>>>>    Tested with jtreg, JPRT.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>> 
>>>>>>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> Can I have your review for this small changes?
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>>>>>> 
>>>>>>>>>>  This is for a enhancement to add head/tail message to the logging files to assist reading GC output.
>>>>>>>>>>  1. modified prompt message if invalid arguments used for log rotating;
>>>>>>>>>>  2. add time and file name message to log file head/tail.
>>>>>>>>>>  3. for easily identify which log file is current, use file name like <filename>.n.current, after it reaches maximum size, rename it to <filename>.n
>>>>>>>>>>       On Windows, there is no F_OK (existing test) definition, F_OK is defined as "0" and for _access of VC++, it just describes:
>>>>>>>>>> 
>>>>>>>>>> modevalue
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Checks file for
>>>>>>>>>> 
>>>>>>>>>> 00
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Existence only
>>>>>>>>>> 
>>>>>>>>>> 02
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Write-only
>>>>>>>>>> 
>>>>>>>>>> 04
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Read-only
>>>>>>>>>> 
>>>>>>>>>> 06
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Read and write
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>>>>>>> The definition are consistent with unistd.h.
>>>>>>>>>> 
>>>>>>>>>>   Test: JPRT and jtreg.
>>>>>>>>>> 
>>>>>>>>>>  Thanks
>>>>>>>>>>  Yumin
>>> 

From ss4766 at att.com  Wed Aug 28 06:53:18 2013
From: ss4766 at att.com (STIRLING, SCOTT)
Date: Wed, 28 Aug 2013 13:53:18 +0000
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <2250E242-628F-4687-9C99-3D061CCEC39F@att.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com>
	<521C5CC8.5060102@oracle.com>, <521CDE52.2030407@oracle.com>,
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>,
	<2250E242-628F-4687-9C99-3D061CCEC39F@att.com>
Message-ID: <B6692EEC-F014-47EE-B575-49799AB13D79@att.com>

As to why (i.e., append to a gc log across process restarts) and can GC tools tolerate logs with multiple JVM histories?

Mainly, appending new history to log file is simple for preserving history, and for text processing and correlating log data later. It's relatively easy to detect where one GC history starts or ends in the same file by the default elapsed time stamp in the GC entries, or by the new date stamp and time stamp options.

The IBM JVM logs are XML of course, and can contain multiple JVM process histories, appending across restarts.

Scott S

On Aug 28, 2013, at 7:16 AM, "STIRLING, SCOTT" <ss4766 at att.com> wrote:

> Always clobbers the last gc log *on JVM restart*, I should say. It's the JVM restart issue where there's no simple way via the JVM to just append to the last GC log if the file exists vs clobber it.
> 
> Scott
> 
> On Aug 28, 2013, at 7:13 AM, "STIRLING, SCOTT" <ss4766 at att.com> wrote:
> 
>> Append vs clobber: with or without rotation, -Xloggc always clobbers the last log. That's why people want a time stamp or pid in the gc file name, IMHO.
>> 
>> Alternatively, give an option to append when -Xloggc is enabled, vs default overwrite.
>> 
>> Kind regards,
>> 
>> Scott Stirling
>> AT&T, Boston
>> 
>> On Aug 27, 2013, at 1:14 PM, "Tao Mao" <tao.mao at oracle.com> wrote:
>> 
>>> 
>>> 
>>> On 8/27/13 1:01 AM, Bengt Rutisson wrote:
>>>> 
>>>> Yumin,
>>>> 
>>>> On 8/26/13 7:01 PM, Yumin Qi wrote:
>>>>> Bengt,
>>>>> 
>>>>> Thanks for your comments.
>>>>> Yes, as you said, the purpose of rotating logs is primarily targeted for saving disk space. This bug is supplying  customers another option to prevent the previous gc logs from removed by restart app without making copy. Now with this pid and time stamp included in file name,  we have more options for users. It is up to user to make decision to or not to keep the logs. We cannot handle all the requests in JVM, but we can offer the choices for users I think. Any way, with either the previous rotating version, or the one I am working, the logs will not grow constantly without limit to blow storage out as long as users give enough attention.
>>>>> 
>>>>> My concern is for no log rotation, should we still use time stamp in file name? I have one version for this, I hope get more comments for that.
>>>> 
>>>> Sorry if I wasn't clear before. I am not worried about the case when log rotation is turned on. What I was worried about was the case where a user is not using log rotation but is still piping the GC output to a file. That file will be overwritten every time the VM is restarted. If we add time stamps to the file name for this case then the file will not be overwritten. I think that is a bit of a scary change. That's all.
>>> 
>>> If you are worried about the case where a user is not using log rotation but creating a new file for each restart, you should be almost equivalently worried about the case where a user is using log rotation and having many rotated logs created which are different for each VM restart. Basically, we are creating even more files over time, which falls into your concern.
>>> 
>>> At this point, I'm fine with either choice for they have pros and cons. If we always append date and time to log file names, customers may say "the logs are 'eating' my disk"; if you don't do that, the customers would still complain the log is overwritten after a restart (I saw these kinds of CR's twice).
>>> 
>>> Thanks.
>>> Tao
>>> 
>>>> 
>>>> Bengt
>>>> 
>>>>> 
>>>>> More comments are appreciated by sending to more wide audience, especially sustaining, they have more experience with customer request.
>>>>> 
>>>>> Thanks
>>>>> Yumin
>>>>> 
>>>>> 
>>>>> 
>>>>> On 8/26/2013 4:47 AM, Bengt Rutisson wrote:
>>>>>> 
>>>>>> Hi Yumin and Tao,
>>>>>> 
>>>>>> I have not reviewed the code change but I have a comment inlined below.
>>>>>> 
>>>>>> On 8/24/13 1:05 AM, Yumin Qi wrote:
>>>>>>> Tao,
>>>>>>> 
>>>>>>> Thanks for your review.
>>>>>>> 
>>>>>>> On 8/23/2013 3:33 PM, Tao Mao wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I reviewed most of the code and test-ran a build from it. It's a very cool and important improvement.
>>>>>>>> 
>>>>>>>> Thank you for putting together these on our wishlist for long.
>>>>>>>> 
>>>>>>>> Below are some comments.
>>>>>>>> 
>>>>>>>> 1. src/share/vm/runtime/arguments.cpp
>>>>>>>> 
>>>>>>>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>>>>>>>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>>>>>>> 
>>>>>>>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>>>>>>> 
>>>>>>>> I worked on a problem of enabling gc log limit over 2G (JDK-7122222). So it seems that customers sometimes want gc logs to be very large.
>>>>>>> Sure, will add.
>>>>>>>> 2. src/share/vm/runtime/arguments.hpp
>>>>>>>> 
>>>>>>>> (1) with the current changeset, we only append date&time to file_name w/ +UseGCLogFileRotation; if not, we won't have date&time info.
>>>>>>>> 
>>>>>>>> I think it would be useful to let both cases (w/ and w/o UseGCLogFileRotation) have date&time in order to solve the overwritten problem (e.g. JDK-8020667). In fact, having that, we actually solve JDK-8020667.
>>>>>>>> 
>>>>>>>> If you want to have that, basically you need to work on the FileStream constructor methods fileStream().
>>>>>>> I can change that, if no objection from others. This also will simplify the setting of file name here.
>>>>>> 
>>>>>> I think appending a timestamp to the log file name is a nice idea, but I think it is also a bit scary. There are users who restart their applications regularly. With the suggested idea such users will now risk filling up their disk space with log files. I imagine that that will not be appreciated by everyone. Such a change should probably be discussed more thoroughly than just in a review request.
>>>>>> 
>>>>>> Thanks,
>>>>>> Bengt
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> (2) Would it be better to rename method name reformat_filename() to extend_filename()?
>>>>>>>> 
>>>>>>>> (3) Typos and suggestion
>>>>>>>> 537 // rotate file in names filename.0, filename.1, ..., filename.<NumberOfGCLogFiles - 1>
>>>>>>>> *=> extended_filename.0*
>>>>>>>> 
>>>>>>>> 538 // filename contains pid and time when the fist file created. The current filename is
>>>>>>>> *=> *the*first *file created.
>>>>>>>> 
>>>>>>>> 539 // gc_log_file_name + pid<pid> + YYYY-MM-DD_HH-MM-SS.<i>.current, where i is current
>>>>>>>> 540 // rotation file number. After it reaches max file size, the file will be saved and
>>>>>>>> 541 // renamed with .current removed from its tail.
>>>>>>> Will change that.
>>>>>>>> 3. For your point 5), I don't quite get it. In my test-run, I tried to change file permission to unreadable and unwritable, but VM would later change the permission back anyway.
>>>>>>>> 
>>>>>>>> So could you bring up some use cases of that functionality to give more details?
>>>>>>> Changing file permission will not stop the file create, in this rotation, the file opened/saved/removed/renamed -> then repeat. What I have done is change the while directory to read only, then the create failed so rotation stopped.
>>>>>>> 
>>>>>>>> 4. Will you write jtreg tests for this functionality? It looks possible to write some tests, at least checking the format of log names.
>>>>>>> Good suggestion, I will add one.
>>>>>>> 
>>>>>>>> Thanks.
>>>>>>>> Tao
>>>>>>>> 
>>>>>>>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>>>>>>>> Could I get  a GC staff review the change? Need more reviewers to push this in.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>> 
>>>>>>>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>>>>>>>> Hi, all
>>>>>>>>>> 
>>>>>>>>>> This is second version after feedback from first round.
>>>>>>>>>> The changes are:
>>>>>>>>>> 
>>>>>>>>>> 1) file name will be based on gc log file name (-Xloggc:filename), pid (process id) and time when the first rotation file created:
>>>>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>>>>>>> 2) If rotate in same file, file name is as in 1), if rotate in multiple files, .<i> will append to above file name.
>>>>>>>>>> 3) every time file rotated, file name and time when file created will be logged to head/tail, this is same as first version.
>>>>>>>>>> 4) current file has name <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>>>>>>>     This is similar to first version.
>>>>>>>>>>     By adapting such name format we will never loss logs in case apps stops and restart, the log files will not be overwritten since time stamp in file names.
>>>>>>>>>> 5) If open file failed, turn off gc log rotation.
>>>>>>>>>>      If due to some reason, file operation failed (such as permission changed etc), with log file opened, logging still works, but at
>>>>>>>>>>      saving and renaming, the file operation will fail, this will lead not all files saved.
>>>>>>>>>> 
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>>>>>>> 
>>>>>>>>>>   Tested with jtreg, JPRT.
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>> 
>>>>>>>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> Can I have your review for this small changes?
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>>>>>>> 
>>>>>>>>>>> This is for a enhancement to add head/tail message to the logging files to assist reading GC output.
>>>>>>>>>>> 1. modified prompt message if invalid arguments used for log rotating;
>>>>>>>>>>> 2. add time and file name message to log file head/tail.
>>>>>>>>>>> 3. for easily identify which log file is current, use file name like <filename>.n.current, after it reaches maximum size, rename it to <filename>.n
>>>>>>>>>>>      On Windows, there is no F_OK (existing test) definition, F_OK is defined as "0" and for _access of VC++, it just describes:
>>>>>>>>>>> 
>>>>>>>>>>> modevalue
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Checks file for
>>>>>>>>>>> 
>>>>>>>>>>> 00
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Existence only
>>>>>>>>>>> 
>>>>>>>>>>> 02
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Write-only
>>>>>>>>>>> 
>>>>>>>>>>> 04
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Read-only
>>>>>>>>>>> 
>>>>>>>>>>> 06
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Read and write
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>>>>>>>> The definition are consistent with unistd.h.
>>>>>>>>>>> 
>>>>>>>>>>>  Test: JPRT and jtreg.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>> 

From karen.kinnear at oracle.com  Wed Aug 28 07:47:31 2013
From: karen.kinnear at oracle.com (karen.kinnear at oracle.com)
Date: Wed, 28 Aug 2013 14:47:31 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8020489: VM crash when non-existent
	interface called by invokespecial
Message-ID: <20130828144736.8BC3148C2A@hg.openjdk.java.net>

Changeset: 915cc4f3fb15
Author:    acorn
Date:      2013-08-28 08:15 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/915cc4f3fb15

8020489: VM crash when non-existent interface called by invokespecial
Reviewed-by: kamg, coleenp

! src/share/vm/classfile/defaultMethods.cpp


From kirk at kodewerk.com  Wed Aug 28 05:38:38 2013
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Wed, 28 Aug 2013 14:38:38 +0200
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>,
	<521CDE52.2030407@oracle.com>
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>
Message-ID: <0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>



> Append vs clobber: with or without rotation, -Xloggc always clobbers the last log. That's why people want a time stamp or pid in the gc file name, IMHO.

My client just clobbered his log files yet... I'd still *not* want the time stamp because this can potentially accidentally fill production disks. Better that my client over wrote the logs than filled his production disk because he didn't realize the behaviour. And, many don't realize the behaviour, they just follow the admin manual.

> 
> Alternatively, give an option to append when -Xloggc is enabled, vs default overwrite.

Allowing an append will break all current analysis tooling.

Regards,
Kirk



From harold.seigel at oracle.com  Wed Aug 28 08:18:30 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 28 Aug 2013 11:18:30 -0400
Subject: RFR JDK-8016764: JVM does not prohibit invokespecial in c.f.v 51.0
	that invokes default interface method in c.f.v 52.0
Message-ID: <521E14C6.8030507@oracle.com>

Hi,

Please review this small fix for bug 8016764.  The change prevents class 
files of version 51 and lower from using invokespecial to call default 
interface methods that are in class files of version 52.

The fix was tested with the JCK Lang and VM tests, ute tests, and some 
of the tests listed in the bug.

Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8016764/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_8016764/>

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

Thanks! Harold

From coleen.phillimore at oracle.com  Wed Aug 28 08:53:49 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 28 Aug 2013 11:53:49 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521D486E.8090207@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
	<521C9F11.5010809@oracle.com> <521D486E.8090207@oracle.com>
Message-ID: <521E1D0D.80307@oracle.com>

On 8/27/2013 8:46 PM, David Holmes wrote:
> Hi Lois,
>
> Thanks for the detailed explanation. It is frustrating that we keep 
> having to revisit these allocation routines.
>
> However it still seems to me that we don't need NO_EXCEPT on most of 
> our operator new definitions because they will never return NULL. This 
> is trivially so for things like:
>
>  void* StackObj::operator new(size_t size)     NOEXCEPT { 
> ShouldNotCallThis(); return 0; }
> void* _ValueObj::operator new(size_t size)    NOEXCEPT { 
> ShouldNotCallThis(); return 0; }
>
> but also for anything that invokes vm_exit_out_of_memory directly or 
> indirectly.

I don't think this is a good idea at all.   We want the constructor 
prologue to always check for null before calling the constructor. We 
will never throw C++ exceptions for these so all operator new's are 
NOEXCEPT.   These trivial examples would return zero rather than 
throwing if ShouldNotCallThis() is ifdef'ed out in product.   So, this 
example is either trivially wrong without NOEXCEPT or correct without 
NOEXCEPT.   It is safer code to make them all NOEXCEPT.

So really the only question is whether NOEXCEPT is better than 
throw().    throw() looks nicer because it's not a macro.  NOEXCEPT may 
be required for the future if that's required to conditionally add the 
noexcept keyword.

Maybe we should use throw() for now and worry about the noexcept keyword 
if that becomes an issue.

David, where are you removing spurious throw() expressions and why?

Thanks,
Coleen

>
> David
> -----
>
> On 27/08/2013 10:44 PM, Lois Foltan wrote:
>>
>> On 8/27/2013 7:31 AM, David Holmes wrote:
>>> On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
>>>> On 2013-08-27 04:41, David Holmes wrote:
>>>>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>>>>> Please review the following fix:
>>>>>>
>>>>>> Internal webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>>>>
>>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file
>>>>>> produced &
>>>>>>           runtime/6878713/Test6878713.sh fails on mac
>>>>>>
>>>>>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>>>
>>>>>> Summary of fix:
>>>>>>      On MacOS, currently Hotspot is built specifying the -fcheck-new
>>>>>> command line option to the llvm-g++ compiler.
>>>>>>      The -fcheck-new option directs the compiler to "check that the
>>>>>> pointer returned by |operator new| is non-null
>>>>>>       before attempting to modify the storage allocated." The 
>>>>>> clang++
>>>>>> compiler does not support the
>>>>>>       -fcheck-new option.  To obtain similiar functionality when
>>>>>> building Hotspot with clang++, empty exception
>>>>>>       throw() specifications must be added to all user-defined
>>>>>> operator
>>>>>> new()'s.
>>>>>
>>>>> We just spotted something related in the PPC64 port and were going 
>>>>> the
>>>>> other way or removing these "spurious" throw() declarations.
>>>>>
>>>>> But this seems really ugly - is there really a need to specialize 
>>>>> this
>>>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
>>>>> honour the nothrow() semantics?
>>>>>
>>>>> That said I thought we already handled this using the "const
>>>>> std::nothrow_t&  nothrow_constant" where needed? Our other 
>>>>> operator new
>>>>> implementations shouldn't return NULL but will abort.
>>>>>
>>>>> So why do we need -fcheck-new or this empty throw() ?
>>>>
>>>> I guess that if the C++ compiler knows that operator new() will 
>>>> throw an
>>>> exception if an allocation fails then it doesn't need to emit code to
>>>> explicitly avoid calling the constructor.
>>>
>>> Yes that is what happens, but why do _we_ need it when ...
>>>
>>>> If we declare operator new() with an empty throw() we will also inform
>>>> the compiler that new can't throw an exception and therefore the
>>>> compiler needs to explicitly handle failed allocations.
>>>
>>> ... we have two kinds of operator new implementations (or at least we
>>> _should_ only have two kinds):
>>>
>>> 1. Will abort on OOM (either ResourceArea exhaustion or Stack
>>> exhaustion) and so never returns NULL
>>> 2. Can return NULL and uses std::nothrow to indicate that
>>>
>>> So we should not need this if the nothrow is acting as I think it
>>> should. Have we missed places where nothrow is needed? Do we have
>>> errant operator new definitions unrelated to the allocation base 
>>> classes?
>> Hi David,
>>
>> I think there may be some confusion about what std::nothrow_t is
>> actually doing.  It provides a mechanism to overload operator new &
>> delete in order to direct the compiler to prefer a function definition
>> that also should contain an empty "throw()" specification.  Take for
>> example the standard definition of the global ::operator new(). It
>> actually looks like:
>>
>>   * void * operator new <a00960.html#a1414bcdb34c39ce82fc84bc8d5287966>
>>     (std::size_t) throw (std::bad_alloc)
>>   * void * operator new <a00960.html#a940b606c7824b4d5dd121199c277d629>
>>     (std::size_t, const std::nothrow_t &) throw ()
>>
>> When the std::nothrow_t parameter is passed to the global ::operator
>> new() the invoked function is the one that also contains an empty
>> throw() specification.  It is due to this empty throw() specification
>> that directs or triggers the C++ compiler to generate the detection of
>> NULL constructor prologue.   Specifying only the std::nothrow_t
>> parameter to a class member user-defined ::operator new() does not
>> indicate to a C++ compiler that the function does not throw an
>> exception.  According to the c++98 standard, a function that will throw
>> no exceptions should be delcared with an empty "throw()" list
>> specification.  When first experimenting with a fix, I did just try to
>> overload Hotspot's user-defined operator new() with the std:nothrow_t
>> parameter.  As expected, the mere presence of this parameter did not
>> trigger the clang++ compiler to generate NULL detection constructor
>> prologue code.  Unfortunately, probably due to legacy code, some C++
>> compilers behave differently.  For example, I did confirm with Solaris
>> C++ development, the Solaris C++ by default always generates constructor
>> prologue code that detects NULL for class member user-defined operator
>> new() even in a throw situation. G++ provides the -fcheck-new command
>> line option.  It is due to these differences of behavior or Hotspot's
>> build specification of -fcheck-new that has led us to believe that
>> std::nothrow_t was providing something that it is not.
>>
>> That said, I would also prefer what you propose, deciding on two kinds
>> of operator new()'s that can be defined.  I did examine all of the
>> user-defined operator new()'s within the code and I determined that only
>> a very small number possibly could not return NULL.  Given this,
>> factored in with the historical reliance on -fcheck-new for the g++
>> compilers, I decided the safe route for JDK 8 was to introduce the
>> NOEXCEPT macro.
>>
>> Lois
>>>
>>> David
>>> -----
>>>
>>>> The g++ man page states:
>>>>
>>>>         -fcheck-new
>>>>             Check that the pointer returned by "operator new" is
>>>> non-null before attempting to modify the storage allocated. This check
>>>> is normally unnecessary because the C++ standard specifies that
>>>>             "operator new" will only return 0 if it is declared 
>>>> throw(),
>>>> in which case the compiler will always check the return value even
>>>> without this option.  In all other cases, when "operator new"
>>>>             has a non-empty exception specification, memory exhaustion
>>>> is signalled by throwing "std::bad_alloc".  See also new (nothrow).
>>>>
>>>> /Mikael
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Tests:
>>>>>>
>>>>>>       Solaris: built fastdebug & product images
>>>>>>       Linux: built fastdebug & product images
>>>>>>       MacOS:  built fastdebug & product images using llvm-g++ - ran
>>>>>> JTREG
>>>>>>                      built fastdebug & product images using 
>>>>>> clang++ -
>>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>>>>       Windows:  built fastdebug & product images with VS2010
>>>>>>
>>


From ss4766 at att.com  Wed Aug 28 08:30:41 2013
From: ss4766 at att.com (STIRLING, SCOTT)
Date: Wed, 28 Aug 2013 15:30:41 +0000
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com>
	<521C5CC8.5060102@oracle.com>,<521CDE52.2030407@oracle.com>
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>,
	<0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>
Message-ID: <8F456566-7610-41F0-A09E-93A56729FBCC@att.com>

Disk overruns can be limited with dedicated log partitions.

Logs can be pre-parsed with command line text tools into separate runs, which everyone already has to do for stack traces in system out/err logs.

IBM logs work great in PMAT, which also keeps pace with ever-evolving parsing nightmare of detailed Hotspot GC logging :-)

Scott

On Aug 28, 2013, at 11:13 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:

> 
> 
>> Append vs clobber: with or without rotation, -Xloggc always clobbers the last log. That's why people want a time stamp or pid in the gc file name, IMHO.
> 
> My client just clobbered his log files yet... I'd still *not* want the time stamp because this can potentially accidentally fill production disks. Better that my client over wrote the logs than filled his production disk because he didn't realize the behaviour. And, many don't realize the behaviour, they just follow the admin manual.
> 
>> 
>> Alternatively, give an option to append when -Xloggc is enabled, vs default overwrite.
> 
> Allowing an append will break all current analysis tooling.
> 
> Regards,
> Kirk
> 
> 

From yumin.qi at oracle.com  Wed Aug 28 09:59:27 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 28 Aug 2013 09:59:27 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <8F456566-7610-41F0-A09E-93A56729FBCC@att.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>,
	<521CDE52.2030407@oracle.com>
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>,
	<0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>
	<8F456566-7610-41F0-A09E-93A56729FBCC@att.com>
Message-ID: <521E2C6F.8020305@oracle.com>

Not sure customer really wants to have  like

-Xloggc:app.log[.%p][.%t]   (whatever the position of %p and %t)

at case rotate gc log or not.
I can add parsing for name pattern with %p and %t, but that really needs 
to have an apprehensive consideration of such change.

Any other opinion?

Yumin

On 8/28/2013 8:30 AM, STIRLING, SCOTT wrote:
> Disk overruns can be limited with dedicated log partitions.
>
> Logs can be pre-parsed with command line text tools into separate runs, which everyone already has to do for stack traces in system out/err logs.
>
> IBM logs work great in PMAT, which also keeps pace with ever-evolving parsing nightmare of detailed Hotspot GC logging :-)
>
> Scott
>
> On Aug 28, 2013, at 11:13 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:
>
>>
>>> Append vs clobber: with or without rotation, -Xloggc always clobbers the last log. That's why people want a time stamp or pid in the gc file name, IMHO.
>> My client just clobbered his log files yet... I'd still *not* want the time stamp because this can potentially accidentally fill production disks. Better that my client over wrote the logs than filled his production disk because he didn't realize the behaviour. And, many don't realize the behaviour, they just follow the admin manual.
>>
>>> Alternatively, give an option to append when -Xloggc is enabled, vs default overwrite.
>> Allowing an append will break all current analysis tooling.
>>
>> Regards,
>> Kirk
>>
>>


From kirk at kodewerk.com  Wed Aug 28 10:30:34 2013
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Wed, 28 Aug 2013 19:30:34 +0200
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521E2C6F.8020305@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>,
	<521CDE52.2030407@oracle.com>
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>,
	<0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>
	<8F456566-7610-41F0-A09E-93A56729FBCC@att.com>
	<521E2C6F.8020305@oracle.com>
Message-ID: <16D04DA4-E0BC-4789-A75E-32B4C094396E@kodewerk.com>



> Not sure customer really wants to have  like
> 
> -Xloggc:app.log[.%p][.%t]   (whatever the position of %p and %t)

Can you explain why you don't believe a customer would not want it? I don't think the following statement isn't grotesque and it's far better than dropping in a surprise.
> 
> 
> I can add parsing for name pattern with %p and %t, but that really needs to have an apprehensive consideration of such change.

I would agree.

Regards,
Kirk


From tao.mao at oracle.com  Wed Aug 28 10:30:55 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Wed, 28 Aug 2013 10:30:55 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521E2C6F.8020305@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>,
	<521CDE52.2030407@oracle.com>
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>,
	<0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>
	<8F456566-7610-41F0-A09E-93A56729FBCC@att.com>
	<521E2C6F.8020305@oracle.com>
Message-ID: <521E33CF.2020306@oracle.com>

How about a flag AppendDataAndTimeToGCLogFileName (and default is false) 
or the like?

Thanks.
Tao

On 8/28/13 9:59 AM, Yumin Qi wrote:
> Not sure customer really wants to have  like
>
> -Xloggc:app.log[.%p][.%t]   (whatever the position of %p and %t)
>
> at case rotate gc log or not.
> I can add parsing for name pattern with %p and %t, but that really 
> needs to have an apprehensive consideration of such change.
>
> Any other opinion?
>
> Yumin
>
> On 8/28/2013 8:30 AM, STIRLING, SCOTT wrote:
>> Disk overruns can be limited with dedicated log partitions.
>>
>> Logs can be pre-parsed with command line text tools into separate 
>> runs, which everyone already has to do for stack traces in system 
>> out/err logs.
>>
>> IBM logs work great in PMAT, which also keeps pace with ever-evolving 
>> parsing nightmare of detailed Hotspot GC logging :-)
>>
>> Scott
>>
>> On Aug 28, 2013, at 11:13 AM, "Kirk Pepperdine" <kirk at kodewerk.com> 
>> wrote:
>>
>>>
>>>> Append vs clobber: with or without rotation, -Xloggc always 
>>>> clobbers the last log. That's why people want a time stamp or pid 
>>>> in the gc file name, IMHO.
>>> My client just clobbered his log files yet... I'd still *not* want 
>>> the time stamp because this can potentially accidentally fill 
>>> production disks. Better that my client over wrote the logs than 
>>> filled his production disk because he didn't realize the behaviour. 
>>> And, many don't realize the behaviour, they just follow the admin 
>>> manual.
>>>
>>>> Alternatively, give an option to append when -Xloggc is enabled, vs 
>>>> default overwrite.
>>> Allowing an append will break all current analysis tooling.
>>>
>>> Regards,
>>> Kirk
>>>
>>>
>

From yumin.qi at oracle.com  Wed Aug 28 10:34:11 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 28 Aug 2013 10:34:11 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521E33CF.2020306@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>,
	<521CDE52.2030407@oracle.com>
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>,
	<0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>
	<8F456566-7610-41F0-A09E-93A56729FBCC@att.com>
	<521E2C6F.8020305@oracle.com> <521E33CF.2020306@oracle.com>
Message-ID: <521E3493.7000208@oracle.com>

I really hate to add more flags, though it does not hurt with one more 
since we already have tons of them.
I think if the pattern exists in file name, we can just replace them 
with pid or timestamp so can save a flag:-)

Thanks
Yumin

On 8/28/2013 10:30 AM, Tao Mao wrote:
> How about a flag AppendDataAndTimeToGCLogFileName (and default is 
> false) or the like?
>
> Thanks.
> Tao
>
> On 8/28/13 9:59 AM, Yumin Qi wrote:
>> Not sure customer really wants to have like
>>
>> -Xloggc:app.log[.%p][.%t]   (whatever the position of %p and %t)
>>
>> at case rotate gc log or not.
>> I can add parsing for name pattern with %p and %t, but that really 
>> needs to have an apprehensive consideration of such change.
>>
>> Any other opinion?
>>
>> Yumin
>>
>> On 8/28/2013 8:30 AM, STIRLING, SCOTT wrote:
>>> Disk overruns can be limited with dedicated log partitions.
>>>
>>> Logs can be pre-parsed with command line text tools into separate 
>>> runs, which everyone already has to do for stack traces in system 
>>> out/err logs.
>>>
>>> IBM logs work great in PMAT, which also keeps pace with 
>>> ever-evolving parsing nightmare of detailed Hotspot GC logging :-)
>>>
>>> Scott
>>>
>>> On Aug 28, 2013, at 11:13 AM, "Kirk Pepperdine" <kirk at kodewerk.com> 
>>> wrote:
>>>
>>>>
>>>>> Append vs clobber: with or without rotation, -Xloggc always 
>>>>> clobbers the last log. That's why people want a time stamp or pid 
>>>>> in the gc file name, IMHO.
>>>> My client just clobbered his log files yet... I'd still *not* want 
>>>> the time stamp because this can potentially accidentally fill 
>>>> production disks. Better that my client over wrote the logs than 
>>>> filled his production disk because he didn't realize the behaviour. 
>>>> And, many don't realize the behaviour, they just follow the admin 
>>>> manual.
>>>>
>>>>> Alternatively, give an option to append when -Xloggc is enabled, 
>>>>> vs default overwrite.
>>>> Allowing an append will break all current analysis tooling.
>>>>
>>>> Regards,
>>>> Kirk
>>>>
>>>>
>>


From kirk at kodewerk.com  Wed Aug 28 10:41:13 2013
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Wed, 28 Aug 2013 19:41:13 +0200
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521E3493.7000208@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>,
	<521CDE52.2030407@oracle.com>
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>,
	<0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>
	<8F456566-7610-41F0-A09E-93A56729FBCC@att.com>
	<521E2C6F.8020305@oracle.com> <521E33CF.2020306@oracle.com>
	<521E3493.7000208@oracle.com>
Message-ID: <32D23C6C-0E50-4614-8F4F-0A32A2C12729@kodewerk.com>



> I really hate to add more flags, though it does not hurt with one more since we already have tons of them.

That is like saying that well, there is already so much litter here that dropping a bit more won't make that big a difference ;-)

Anyways, what people using *nix tend to drop a timestamp in using something like -Xloggc:gc`date`.log At least this would be cross platform solution.

More over it won't break anything that is already there.. or will it? If someone puts %p in a file name they are now going to see a pid.

Regards,
Kirk


From tao.mao at oracle.com  Wed Aug 28 10:45:19 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Wed, 28 Aug 2013 10:45:19 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521E3493.7000208@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>,
	<521CDE52.2030407@oracle.com>
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>,
	<0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>
	<8F456566-7610-41F0-A09E-93A56729FBCC@att.com>
	<521E2C6F.8020305@oracle.com> <521E33CF.2020306@oracle.com>
	<521E3493.7000208@oracle.com>
Message-ID: <521E372F.7060808@oracle.com>

Yumin,

To be honest, I hate to add any more flags too. I'm with you :-)

But, the fact is sometimes we have to. The way you proposed to parse the 
gc log file name is not that intuitive so we set one more block on the 
learning curve, whereas users seem to get used to set a flag. That's why 
I prefer just adding one more flag. At this point, you need to make your 
own call since you have seen all these arguments in this thread.

My 2?.

Tao


On 8/28/13 10:34 AM, Yumin Qi wrote:
> I really hate to add more flags, though it does not hurt with one more 
> since we already have tons of them.
> I think if the pattern exists in file name, we can just replace them 
> with pid or timestamp so can save a flag:-)
>
> Thanks
> Yumin
>
> On 8/28/2013 10:30 AM, Tao Mao wrote:
>> How about a flag AppendDataAndTimeToGCLogFileName (and default is 
>> false) or the like?
>>
>> Thanks.
>> Tao
>>
>> On 8/28/13 9:59 AM, Yumin Qi wrote:
>>> Not sure customer really wants to have like
>>>
>>> -Xloggc:app.log[.%p][.%t]   (whatever the position of %p and %t)
>>>
>>> at case rotate gc log or not.
>>> I can add parsing for name pattern with %p and %t, but that really 
>>> needs to have an apprehensive consideration of such change.
>>>
>>> Any other opinion?
>>>
>>> Yumin
>>>
>>> On 8/28/2013 8:30 AM, STIRLING, SCOTT wrote:
>>>> Disk overruns can be limited with dedicated log partitions.
>>>>
>>>> Logs can be pre-parsed with command line text tools into separate 
>>>> runs, which everyone already has to do for stack traces in system 
>>>> out/err logs.
>>>>
>>>> IBM logs work great in PMAT, which also keeps pace with 
>>>> ever-evolving parsing nightmare of detailed Hotspot GC logging :-)
>>>>
>>>> Scott
>>>>
>>>> On Aug 28, 2013, at 11:13 AM, "Kirk Pepperdine" <kirk at kodewerk.com> 
>>>> wrote:
>>>>
>>>>>
>>>>>> Append vs clobber: with or without rotation, -Xloggc always 
>>>>>> clobbers the last log. That's why people want a time stamp or pid 
>>>>>> in the gc file name, IMHO.
>>>>> My client just clobbered his log files yet... I'd still *not* want 
>>>>> the time stamp because this can potentially accidentally fill 
>>>>> production disks. Better that my client over wrote the logs than 
>>>>> filled his production disk because he didn't realize the 
>>>>> behaviour. And, many don't realize the behaviour, they just follow 
>>>>> the admin manual.
>>>>>
>>>>>> Alternatively, give an option to append when -Xloggc is enabled, 
>>>>>> vs default overwrite.
>>>>> Allowing an append will break all current analysis tooling.
>>>>>
>>>>> Regards,
>>>>> Kirk
>>>>>
>>>>>
>>>
>

From lois.foltan at oracle.com  Wed Aug 28 10:56:43 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 28 Aug 2013 13:56:43 -0400
Subject: RFR JDK-8022407 (round 2) sun/misc/CopyMemory.java fails with SIGSEGV
	in Unsafe_SetByte+0x35
In-Reply-To: <521CD14D.5040809@oracle.com>
References: <521CD14D.5040809@oracle.com>
Message-ID: <521E39DB.1050901@oracle.com>


Please review the updated webrev:
     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407.2/

Bug:
     bug link at https://bugs.openjdk.java.net/browse/JDK-8022407

Summary of fix:

     The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ 
compiler, exhibited a compiler
     optimization issue when prims/unsafe.cpp was compiled at the 
default -Os level. As a work around
     fix, knock the optimization level down down to -O1.

Tests: MacOS: built fastdebug & product images using clang++ (ran JTREG 
& vm.quick.testlist)
           built using llvm-g++ to verifyprims/unsafe.cpp remained 
compiled at -Os

Thank you, Lois



From lois.foltan at oracle.com  Wed Aug 28 10:58:36 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 28 Aug 2013 13:58:36 -0400
Subject: RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV in
	Unsafe_SetByte+0x35
In-Reply-To: <E2EB7082-EC20-4635-B15A-BDF9340C7494@oracle.com>
References: <521BFA78.9070908@oracle.com> <521CD14D.5040809@oracle.com>
	<5CDAD4D1-5A6C-45EC-AAF3-4CB09FD76344@oracle.com>
	<521D005D.4050004@oracle.com> <521D0673.6070106@oracle.com>
	<E2EB7082-EC20-4635-B15A-BDF9340C7494@oracle.com>
Message-ID: <521E3A4C.5070603@oracle.com>

Hi Christian,

Thanks for the review.  I completed the change to only knock the 
optimization level  down to -O1 for the file prims/unsafe.cpp.

Lois

On 8/27/2013 9:15 PM, Christian Thalinger wrote:
> On Aug 27, 2013, at 1:05 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>> On 08/27/2013 03:39 PM, Lois Foltan wrote:
>>> On 8/27/2013 1:29 PM, Christian Thalinger wrote:
>>>> On Aug 27, 2013, at 9:18 AM, Lois Foltan <lois.foltan at oracle.com> wrote:
>>>>
>>>>> Please review the following fix:
>>>>>     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/
>>>>>
>>>>> Bug:
>>>>>     bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>>>>
>>>>> Summary of fix:
>>>>>
>>>>> The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ compiler, exhibited a compiler optimization issue when prims/unsafe.cpp was compiled at the default -Os level. As a work around fix, knock the optimization level down down to -O0.
>>>> Why are we lowering to -O0 when you state in the bug report that -O1 also works?  What is the code that breaks?
>>>>
>>>> -- Chris
>>> Hi Chris,
>>> The convention within make/bsd/makefiles/gcc.make indicated that historically files that exhibited C++ compiler optimization issues were knocked down to /NOOPT or -O0.  I did also check with Coleen to make sure that prims/unsafe.cpp was not a performance critical file.
>> So my advice was that it wasn't performance critical - because it's mostly calls from Java.  Except for maybe the anonymous class functions.  If you disagree, let us know.
> I agree.  Most of the (performance critical) Unsafe methods are intrinsified anyway but why waste computing cycles and more importantly bytes (in object size) if we don't have to.
>
> -- Chris
>
>> Coleen
>>
>>> -O1 does add some optimizations on top of -O0 but not inlining.  I will recheck testing with -O1 to confirm and change unsafe.cpp's optimization level to -O1 if testing yields good results.
>>>
>>> I suspect the optimization problem is in unsafe.cpp's definition of Unsafe_GetNativeByte.  I had left off tracking it at that level and certainly will not close the JDK bug until I can narrow in further and hopefully report to the clang compiler team.
>>>
>>> Thanks,
>>> Lois
>>>>> Tests:
>>>>>     MacOS: built fastdebug & product images using clang++ (ran JTREG & vm.quick.testlist)
>>>>>                    built using llvm-g++ to verify prims/unsafe.cpp remained compiled at -Os
>>>>>
>>>>> Thank you,
>>>>> Lois
>>>>>
>>>>>


From lois.foltan at oracle.com  Wed Aug 28 11:19:09 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 28 Aug 2013 14:19:09 -0400
Subject: Fwd: Re: RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV
	in Unsafe_SetByte+0x35
In-Reply-To: <521E3D00.1030706@oracle.com>
References: <521E3D00.1030706@oracle.com>
Message-ID: <521E3F1D.80100@oracle.com>


Forwarding to include the openjdk distribution lists.

Lois


-------- Original Message --------
Subject: 	Re: RFR JDK-8022407 sun/misc/CopyMemory.java fails with 
SIGSEGV in Unsafe_SetByte+0x35
Date: 	Wed, 28 Aug 2013 14:10:08 -0400
From: 	Lois Foltan <lois.foltan at oracle.com>
Organization: 	Oracle Corporation
To: 	David Holmes <david.holmes at oracle.com>
CC: 	Coleen Phillimore <coleen.phillimore at oracle.com>



Hi David,

Thanks for the review.  In this situation for the file, -O1 is a valid 
work around and I have sent out a second round of review request.  I 
also have one additional comment see interspersed below.

Lois

On 8/27/2013 8:50 PM, David Holmes wrote:
> <offlist>
>
> From past observation the normal way we handle this is to drop the 
> optimization level one notch at a time until it works. That way we 
> maintain maximum optimization and by seeing what optimizations are 
> performed at each level we can generally narrow it down to a specific 
> optimization that can be disabled.
Clang does not support the same -f<specific_optimization> command line 
options that gcc does.  From the documentation I could find the 
difference between -O1 (passes) and -O2 (fails) for clang are

  *

    -O2 is based on -01

      o /adds/: -inline -memdep -globaldce -constmerge
      o /removes/: -always-inline

However, you can not pass these options directly to clang.  From my take 
on this one must compile with -emit-llvm to generate llvm IR/bitcode and 
then pipe the resulting file into the opt phase. So not feasible for our 
build makefiles but should help me further narrow down which 
optimization is causing the issue. Thanks again for the tip on how this 
is usually handled.

Lois
> David
>
> On 28/08/2013 6:05 AM, Coleen Phillimore wrote:
>>
>> On 08/27/2013 03:39 PM, Lois Foltan wrote:
>>>
>>> On 8/27/2013 1:29 PM, Christian Thalinger wrote:
>>>> On Aug 27, 2013, at 9:18 AM, Lois Foltan <lois.foltan at oracle.com> 
>>>> wrote:
>>>>
>>>>> Please review the following fix:
>>>>>     open webrev at 
>>>>> http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/
>>>>>
>>>>> Bug:
>>>>>     bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>>>>
>>>>> Summary of fix:
>>>>>
>>>>> The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++
>>>>> compiler, exhibited a compiler optimization issue when
>>>>> prims/unsafe.cpp was compiled at the default -Os level. As a work
>>>>> around fix, knock the optimization level down down to -O0.
>>>> Why are we lowering to -O0 when you state in the bug report that -O1
>>>> also works?  What is the code that breaks?
>>>>
>>>> -- Chris
>>> Hi Chris,
>>> The convention within make/bsd/makefiles/gcc.make indicated that
>>> historically files that exhibited C++ compiler optimization issues
>>> were knocked down to /NOOPT or -O0.  I did also check with Coleen to
>>> make sure that prims/unsafe.cpp was not a performance critical file.
>>
>> So my advice was that it wasn't performance critical - because it's
>> mostly calls from Java.  Except for maybe the anonymous class
>> functions.  If you disagree, let us know.
>>
>> Coleen
>>
>>> -O1 does add some optimizations on top of -O0 but not inlining.  I
>>> will recheck testing with -O1 to confirm and change unsafe.cpp's
>>> optimization level to -O1 if testing yields good results.
>>>
>>> I suspect the optimization problem is in unsafe.cpp's definition of
>>> Unsafe_GetNativeByte.  I had left off tracking it at that level and
>>> certainly will not close the JDK bug until I can narrow in further and
>>> hopefully report to the clang compiler team.
>>>
>>> Thanks,
>>> Lois
>>>>> Tests:
>>>>>     MacOS: built fastdebug & product images using clang++ (ran JTREG
>>>>> & vm.quick.testlist)
>>>>>                    built using llvm-g++ to verify prims/unsafe.cpp
>>>>> remained compiled at -Os
>>>>>
>>>>> Thank you,
>>>>> Lois
>>>>>
>>>>>
>>>
>>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130828/4ea68c72/attachment.html 

From lois.foltan at oracle.com  Wed Aug 28 11:20:26 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 28 Aug 2013 14:20:26 -0400
Subject: RFR JDK-8022407 (round 2) sun/misc/CopyMemory.java fails with
	SIGSEGV in Unsafe_SetByte+0x35
In-Reply-To: <521E3D69.4030202@oracle.com>
References: <521CD14D.5040809@oracle.com> <521E39DB.1050901@oracle.com>
	<521E3D69.4030202@oracle.com>
Message-ID: <521E3F6A.7080200@oracle.com>


Thanks Coleen for the review.  I'm cc'ing openjdk distribution lists on 
this reply.

Lois

On 8/28/2013 2:11 PM, Coleen Phillimore wrote:
>
> Looks good.
> Coleen
>
> On 8/28/2013 1:56 PM, Lois Foltan wrote:
>>
>> Please review the updated webrev:
>>     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407.2/
>>
>> Bug:
>>     bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>
>> Summary of fix:
>>
>>     The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ 
>> compiler, exhibited a compiler
>>     optimization issue when prims/unsafe.cpp was compiled at the 
>> default -Os level. As a work around
>>     fix, knock the optimization level down down to -O1.
>>
>> Tests: MacOS: built fastdebug & product images using clang++ (ran 
>> JTREG & vm.quick.testlist)
>>           built using llvm-g++ to verifyprims/unsafe.cpp remained 
>> compiled at -Os
>>
>> Thank you, Lois
>>
>>
>


From bill.pittore at oracle.com  Wed Aug 28 11:29:18 2013
From: bill.pittore at oracle.com (BILL PITTORE)
Date: Wed, 28 Aug 2013 14:29:18 -0400
Subject: RFR - 8023580 - Add jtreg test for 8004051 and 8005722
In-Reply-To: <5216532C.3080802@oracle.com>
References: <5216532C.3080802@oracle.com>
Message-ID: <521E417E.2000207@oracle.com>

Added serviceability.

bill


On 8/22/2013 2:06 PM, BILL PITTORE wrote:
> Would like a review of the following test being added to 
> hotspot/test/compiler that tests an assertion failure for both 8004051 
> and 8005722.
>
> http://cr.openjdk.java.net/~bpittore/8023580/webrev.00/
>
> thanks,
> bill
>
>



From bill.pittore at oracle.com  Wed Aug 28 11:37:20 2013
From: bill.pittore at oracle.com (BILL PITTORE)
Date: Wed, 28 Aug 2013 14:37:20 -0400
Subject: Fwd: Re: RFR - 8023580 - Add jtreg test for 8004051 and 8005722
In-Reply-To: <521E42CE.7060603@oracle.com>
References: <52165AA4.40803@oracle.com> <521E42CE.7060603@oracle.com>
Message-ID: <521E4360.3040803@oracle.com>

Thanks!  I meant to forward to compiler list but mistakenly sent to 
serviceability.

bill

On 8/28/2013 2:34 PM, Vladimir Kozlov wrote:
> Bill,
>
> I did reviewed it but forgot to include you in reply.
>
> Vladimir
>
> -------- Original Message --------
> Subject: Re: RFR - 8023580 - Add jtreg test for 8004051 and 8005722
> Date: Thu, 22 Aug 2013 11:38:28 -0700
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>
> Looks good.
> Redirected to compiler alias since it is C1 compiler test.
>
> Vladimir
>
> On 8/22/13 11:06 AM, BILL PITTORE wrote:
>> Would like a review of the following test being added to
>> hotspot/test/compiler that tests an assertion failure for both 8004051
>> and 8005722.
>>
>> http://cr.openjdk.java.net/~bpittore/8023580/webrev.00/
>>
>> thanks,
>> bill
>>
>>
>
>



From karen.kinnear at oracle.com  Wed Aug 28 12:35:46 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 28 Aug 2013 15:35:46 -0400
Subject: RFR JDK-8016764: JVM does not prohibit invokespecial in c.f.v
	51.0 that invokes default interface method in c.f.v 52.0
In-Reply-To: <521E14C6.8030507@oracle.com>
References: <521E14C6.8030507@oracle.com>
Message-ID: <854B5F60-D2BA-4AB5-854C-D0F6D1BA02AB@oracle.com>

Harold,

Looks great. Thank you so much for doing this and for the extra testing.

thanks,
Karen

On Aug 28, 2013, at 11:18 AM, harold seigel wrote:

> Hi,
> 
> Please review this small fix for bug 8016764.  The change prevents class files of version 51 and lower from using invokespecial to call default interface methods that are in class files of version 52.
> 
> The fix was tested with the JCK Lang and VM tests, ute tests, and some of the tests listed in the bug.
> 
> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8016764/ <http://cr.openjdk.java.net/%7Ehseigel/bug_8016764/>
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8016764
> 
> Thanks! Harold


From Karen.Kinnear at oracle.com  Wed Aug 28 12:42:37 2013
From: Karen.Kinnear at oracle.com (Karen Kinnear)
Date: Wed, 28 Aug 2013 15:42:37 -0400
Subject: S RFR: Lambda: verification error in generated lambda classes
Message-ID: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>

Please review - lambda team needs this change to get in by tomorrow so they can push
the (8010433) metafactory change which is waiting on the vm. Thanks.


webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
http://bugs.sun.com/view_bug.do?bug_id=8023872

Testing:
The failure comes if you apply an early patch of 8010433 to the jdk and do not
make the vm change. So testing included 4 binaries: master, newjdk, newvm, newjdkvm

jtreg for SpinedBufferTest with various flags - these are the expected results below
The key point is newjdk -Xverify: all fails
newjdkvm -Xverify:all passes, but if you also turn on -XX:+VerifyLambdaBytecodes you see
   the verification error

1. master
 no flags: timed out
 -Xverify:all: timed out
 -XX:+VerifyReflectionBytecodes: VerifyError in reflection

2. newjdk
 no flags: timed out
 -Xverify:all
   java.lang.BootstrapMethodError: call site initialization exception ... cause: 
     VerifyError: Bad invokespecial instruction: current class isn't assignable to reference class
 -XX:+VerifyReflectionBytecodes: VerifyError in reflection

3. newvm
  no flags: timed out
  rerun.sh: -Xverify:all: passed
  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
  -XX:+VerifyLambdaBytecodes: passed, didn't try verification
  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed

4. newjdkvm
 rerun.sh: no flags: passed
 rerun.verify.sh: -Xverify:all: passed
 rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: 
   Verification for java.util.streamIntPipeline$7$1$$Lambda$9 failed 

regression testing:
newvm:
  vm.quick.testlist - in progress
  jtreg java/util/stream - in progress
  jprt -stree . - in progress

newvmjdk (Brian testing in lambda repo) - in progress

thanks,
Karen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130828/0de20f62/attachment.html 

From kamggg at gmail.com  Wed Aug 28 12:55:18 2013
From: kamggg at gmail.com (Keith McGuigan)
Date: Wed, 28 Aug 2013 15:55:18 -0400
Subject: RFR JDK-8016764: JVM does not prohibit invokespecial in c.f.v
	51.0 that invokes default interface method in c.f.v 52.0
In-Reply-To: <854B5F60-D2BA-4AB5-854C-D0F6D1BA02AB@oracle.com>
References: <521E14C6.8030507@oracle.com>
	<854B5F60-D2BA-4AB5-854C-D0F6D1BA02AB@oracle.com>
Message-ID: <CAFUO74nevxxu76OJjjQjBsTmzyb6QnOsaHwUh9THywscEX8LeA@mail.gmail.com>

Yeah looks fine to me too.


On Wed, Aug 28, 2013 at 3:35 PM, Karen Kinnear <karen.kinnear at oracle.com>wrote:

> Harold,
>
> Looks great. Thank you so much for doing this and for the extra testing.
>
> thanks,
> Karen
>
> On Aug 28, 2013, at 11:18 AM, harold seigel wrote:
>
> > Hi,
> >
> > Please review this small fix for bug 8016764.  The change prevents class
> files of version 51 and lower from using invokespecial to call default
> interface methods that are in class files of version 52.
> >
> > The fix was tested with the JCK Lang and VM tests, ute tests, and some
> of the tests listed in the bug.
> >
> > Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8016764/ <
> http://cr.openjdk.java.net/%7Ehseigel/bug_8016764/>
> >
> > bug: https://bugs.openjdk.java.net/browse/JDK-8016764
> >
> > Thanks! Harold
>
>


-- 
- Keith McGuigan <keith.mcguigan at alumni.unh.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130828/ef7fa528/attachment.html 

From harold.seigel at oracle.com  Wed Aug 28 13:10:54 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 28 Aug 2013 16:10:54 -0400
Subject: RFR JDK-8016764: JVM does not prohibit invokespecial in c.f.v
	51.0 that invokes default interface method in c.f.v 52.0
In-Reply-To: <CAFUO74nevxxu76OJjjQjBsTmzyb6QnOsaHwUh9THywscEX8LeA@mail.gmail.com>
References: <521E14C6.8030507@oracle.com>
	<854B5F60-D2BA-4AB5-854C-D0F6D1BA02AB@oracle.com>
	<CAFUO74nevxxu76OJjjQjBsTmzyb6QnOsaHwUh9THywscEX8LeA@mail.gmail.com>
Message-ID: <521E594E.8080100@oracle.com>

Hi Keith,

Thanks for reviewing this.

Harold

On 8/28/2013 3:55 PM, Keith McGuigan wrote:
> Yeah looks fine to me too.
>
>
> On Wed, Aug 28, 2013 at 3:35 PM, Karen Kinnear 
> <karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>> wrote:
>
>     Harold,
>
>     Looks great. Thank you so much for doing this and for the extra
>     testing.
>
>     thanks,
>     Karen
>
>     On Aug 28, 2013, at 11:18 AM, harold seigel wrote:
>
>     > Hi,
>     >
>     > Please review this small fix for bug 8016764.  The change
>     prevents class files of version 51 and lower from using
>     invokespecial to call default interface methods that are in class
>     files of version 52.
>     >
>     > The fix was tested with the JCK Lang and VM tests, ute tests,
>     and some of the tests listed in the bug.
>     >
>     > Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8016764/
>     <http://cr.openjdk.java.net/%7Ehseigel/bug_8016764/>
>     <http://cr.openjdk.java.net/%7Ehseigel/bug_8016764/>
>     >
>     > bug: https://bugs.openjdk.java.net/browse/JDK-8016764
>     >
>     > Thanks! Harold
>
>
>
>
> -- 
> - Keith McGuigan <keith.mcguigan at alumni.unh.edu 
> <mailto:keith.mcguigan at alumni.unh.edu>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130828/a6f308a0/attachment.html 

From harold.seigel at oracle.com  Wed Aug 28 13:11:21 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 28 Aug 2013 16:11:21 -0400
Subject: RFR JDK-8016764: JVM does not prohibit invokespecial in c.f.v
	51.0 that invokes default interface method in c.f.v 52.0
In-Reply-To: <854B5F60-D2BA-4AB5-854C-D0F6D1BA02AB@oracle.com>
References: <521E14C6.8030507@oracle.com>
	<854B5F60-D2BA-4AB5-854C-D0F6D1BA02AB@oracle.com>
Message-ID: <521E5969.8080607@oracle.com>

Hi Karen,

Thanks for the review.

Harold

On 8/28/2013 3:35 PM, Karen Kinnear wrote:
> Harold,
>
> Looks great. Thank you so much for doing this and for the extra testing.
>
> thanks,
> Karen
>
> On Aug 28, 2013, at 11:18 AM, harold seigel wrote:
>
>> Hi,
>>
>> Please review this small fix for bug 8016764.  The change prevents class files of version 51 and lower from using invokespecial to call default interface methods that are in class files of version 52.
>>
>> The fix was tested with the JCK Lang and VM tests, ute tests, and some of the tests listed in the bug.
>>
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8016764/ <http://cr.openjdk.java.net/%7Ehseigel/bug_8016764/>
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8016764
>>
>> Thanks! Harold


From suenaga.yasumasa at lab.ntt.co.jp  Wed Aug 28 16:54:01 2013
From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga)
Date: Thu, 29 Aug 2013 08:54:01 +0900
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521E3493.7000208@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>,
	<521CDE52.2030407@oracle.com>
	<D06609A2-0DF1-4A62-9AD7-770D048A5029@att.com>,
	<0CA8ED1A-85B5-4E82-8A09-98D9BF48271F@kodewerk.com>
	<8F456566-7610-41F0-A09E-93A56729FBCC@att.com>
	<521E2C6F.8020305@oracle.com> <521E33CF.2020306@oracle.com>
	<521E3493.7000208@oracle.com>
Message-ID: <521E8D99.1040708@lab.ntt.co.jp>

> I think if the pattern exists in file name, we can just replace them with pid or timestamp so can save a flag:-)

Do you say that you will implement "6950794: Make the GC log file name parameterized" ?

JDK-6950794: Make the GC log file name parameterized
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6950794

Patch:
   http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html

A few days ago, I introduced this RFE:
   http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html
   http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008031.html


Yasumasa
   
On 2013/08/29 2:34, Yumin Qi wrote:
> I really hate to add more flags, though it does not hurt with one more since we already have tons of them.
> I think if the pattern exists in file name, we can just replace them with pid or timestamp so can save a flag:-)
>
> Thanks
> Yumin
>
> On 8/28/2013 10:30 AM, Tao Mao wrote:
>> How about a flag AppendDataAndTimeToGCLogFileName (and default is false) or the like?
>>
>> Thanks.
>> Tao
>>
>> On 8/28/13 9:59 AM, Yumin Qi wrote:
>>> Not sure customer really wants to have like
>>>
>>> -Xloggc:app.log[.%p][.%t] (whatever the position of %p and %t)
>>>
>>> at case rotate gc log or not.
>>> I can add parsing for name pattern with %p and %t, but that really needs to have an apprehensive consideration of such change.
>>>
>>> Any other opinion?
>>>
>>> Yumin
>>>
>>> On 8/28/2013 8:30 AM, STIRLING, SCOTT wrote:
>>>> Disk overruns can be limited with dedicated log partitions.
>>>>
>>>> Logs can be pre-parsed with command line text tools into separate runs, which everyone already has to do for stack traces in system out/err logs.
>>>>
>>>> IBM logs work great in PMAT, which also keeps pace with ever-evolving parsing nightmare of detailed Hotspot GC logging :-)
>>>>
>>>> Scott
>>>>
>>>> On Aug 28, 2013, at 11:13 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:
>>>>
>>>>>
>>>>>> Append vs clobber: with or without rotation, -Xloggc always clobbers the last log. That's why people want a time stamp or pid in the gc file name, IMHO.
>>>>> My client just clobbered his log files yet... I'd still *not* want the time stamp because this can potentially accidentally fill production disks. Better that my client over wrote the logs than filled his production disk because he didn't realize the behaviour. And, many don't realize the behaviour, they just follow the admin manual.
>>>>>
>>>>>> Alternatively, give an option to append when -Xloggc is enabled, vs default overwrite.
>>>>> Allowing an append will break all current analysis tooling.
>>>>>
>>>>> Regards,
>>>>> Kirk
>>>>>
>>>>>
>>>


From david.holmes at oracle.com  Wed Aug 28 17:48:05 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 29 Aug 2013 10:48:05 +1000
Subject: S RFR: Lambda: verification error in generated lambda classes
In-Reply-To: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
References: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
Message-ID: <521E9A45.8040809@oracle.com>

Hi Karen,

I found the boolean logic very hard to follow there - not sure if the 
refactoring helped or hindered :)

But it looks okay.

David

On 29/08/2013 5:42 AM, Karen Kinnear wrote:
> Please review - lambda team needs this change to get in by tomorrow so
> they can push
> the (8010433) metafactory change which is waiting on the vm. Thanks.
>
>
> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
> http://bugs.sun.com/view_bug.do?bug_id=8023872
>
> Testing:
> The failure comes if you apply an early patch of 8010433 to the jdk and
> do not
> make the vm change. So testing included 4 binaries: master, newjdk,
> newvm, newjdkvm
>
> jtreg for SpinedBufferTest with various flags - these are the expected
> results below
> The key point is newjdk -Xverify: all fails
> newjdkvm -Xverify:all passes, but if you also turn on
> -XX:+VerifyLambdaBytecodes you see
>     the verification error
>
> 1. master
>   no flags: timed out
>   -Xverify:all: timed out
>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>
> 2. newjdk
>   no flags: timed out
>   -Xverify:all
>     java.lang.BootstrapMethodError: call site initialization exception
> ... cause:
>       VerifyError: Bad invokespecial instruction: current class isn't
> assignable to reference class
>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>
> 3. newvm
>    no flags: timed out
>    rerun.sh: -Xverify:all: passed
>    -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>    -XX:+VerifyLambdaBytecodes: passed, didn't try verification
>    rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
>
> 4. newjdkvm
>   rerun.sh: no flags: passed
>   rerun.verify.sh: -Xverify:all: passed
>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
>     Verification for java.util.streamIntPipeline$7$1$$Lambda$9 failed
>
> regression testing:
> newvm:
>    vm.quick.testlist - in progress
>    jtreg java/util/stream - in progress
>    jprt -stree . - in progress
>
> newvmjdk (Brian testing in lambda repo) - in progress
>
> thanks,
> Karen
>

From Karen.Kinnear at oracle.com  Wed Aug 28 17:50:36 2013
From: Karen.Kinnear at oracle.com (Karen Kinnear)
Date: Wed, 28 Aug 2013 20:50:36 -0400
Subject: S RFR: Lambda: verification error in generated lambda classes
In-Reply-To: <521E9A45.8040809@oracle.com>
References: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
	<521E9A45.8040809@oracle.com>
Message-ID: <491B7272-B309-4193-BF8B-E7889441B6FB@oracle.com>

Thank you David. I agree, I was tempted to rewrite the entire method - in particular, in a debugger
(so I didn't check the optimized code) we walk the entire && before we make the initial call - in this
case the initial call would weed out more things faster potentially, so ... But I chose not to rewrite since
they need this quickly and the shaking out would take quite a bit longer.

thanks for the review,
Karen

On Aug 28, 2013, at 8:48 PM, David Holmes wrote:

> Hi Karen,
> 
> I found the boolean logic very hard to follow there - not sure if the refactoring helped or hindered :)
> 
> But it looks okay.
> 
> David
> 
> On 29/08/2013 5:42 AM, Karen Kinnear wrote:
>> Please review - lambda team needs this change to get in by tomorrow so
>> they can push
>> the (8010433) metafactory change which is waiting on the vm. Thanks.
>> 
>> 
>> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
>> http://bugs.sun.com/view_bug.do?bug_id=8023872
>> 
>> Testing:
>> The failure comes if you apply an early patch of 8010433 to the jdk and
>> do not
>> make the vm change. So testing included 4 binaries: master, newjdk,
>> newvm, newjdkvm
>> 
>> jtreg for SpinedBufferTest with various flags - these are the expected
>> results below
>> The key point is newjdk -Xverify: all fails
>> newjdkvm -Xverify:all passes, but if you also turn on
>> -XX:+VerifyLambdaBytecodes you see
>>    the verification error
>> 
>> 1. master
>>  no flags: timed out
>>  -Xverify:all: timed out
>>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> 
>> 2. newjdk
>>  no flags: timed out
>>  -Xverify:all
>>    java.lang.BootstrapMethodError: call site initialization exception
>> ... cause:
>>      VerifyError: Bad invokespecial instruction: current class isn't
>> assignable to reference class
>>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> 
>> 3. newvm
>>   no flags: timed out
>>   rerun.sh: -Xverify:all: passed
>>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>   -XX:+VerifyLambdaBytecodes: passed, didn't try verification
>>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
>> 
>> 4. newjdkvm
>>  rerun.sh: no flags: passed
>>  rerun.verify.sh: -Xverify:all: passed
>>  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
>>    Verification for java.util.streamIntPipeline$7$1$$Lambda$9 failed
>> 
>> regression testing:
>> newvm:
>>   vm.quick.testlist - in progress
>>   jtreg java/util/stream - in progress
>>   jprt -stree . - in progress
>> 
>> newvmjdk (Brian testing in lambda repo) - in progress
>> 
>> thanks,
>> Karen
>> 


From david.holmes at oracle.com  Wed Aug 28 17:52:23 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 29 Aug 2013 10:52:23 +1000
Subject: RFR JDK-8016764: JVM does not prohibit invokespecial in c.f.v
	51.0 that invokes default interface method in c.f.v 52.0
In-Reply-To: <521E14C6.8030507@oracle.com>
References: <521E14C6.8030507@oracle.com>
Message-ID: <521E9B47.9070409@oracle.com>

Hi Harold,

On 29/08/2013 1:18 AM, harold seigel wrote:
> Hi,
>
> Please review this small fix for bug 8016764.  The change prevents class
> files of version 51 and lower from using invokespecial to call default
> interface methods that are in class files of version 52.

I don't have much knowledge of the verifier but I don't see anything 
that refers to the class file versions involved. Is it implicit in the 
fact we got to this particular piece of code?

Thanks,
David

> The fix was tested with the JCK Lang and VM tests, ute tests, and some
> of the tests listed in the bug.
>
> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8016764/
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8016764/>
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8016764
>
> Thanks! Harold

From harold.seigel at oracle.com  Wed Aug 28 18:19:14 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 28 Aug 2013 21:19:14 -0400
Subject: RFR JDK-8016764: JVM does not prohibit invokespecial in c.f.v
	51.0 that invokes default interface method in c.f.v 52.0
In-Reply-To: <521E9B47.9070409@oracle.com>
References: <521E14C6.8030507@oracle.com> <521E9B47.9070409@oracle.com>
Message-ID: <521EA192.4060109@oracle.com>

Hi David,

The removal of the two lines causes the _invokespecial case to fall 
through to the _invokestatic case.

The _invokestatic case checks to see if _klass->major_version() is less 
than STATIC_METHOD_IN_INTERFACE_MAJOR_VERSION.  That is a comparison of 
class file versions.

If klass->major_version() is less than 52 then the constantpool entry 
can only be a Methodref.

Does that help clarify things?

Thanks, Harold

On 8/28/2013 8:52 PM, David Holmes wrote:
> Hi Harold,
>
> On 29/08/2013 1:18 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this small fix for bug 8016764.  The change prevents class
>> files of version 51 and lower from using invokespecial to call default
>> interface methods that are in class files of version 52.
>
> I don't have much knowledge of the verifier but I don't see anything 
> that refers to the class file versions involved. Is it implicit in the 
> fact we got to this particular piece of code?
>
> Thanks,
> David
>
>> The fix was tested with the JCK Lang and VM tests, ute tests, and some
>> of the tests listed in the bug.
>>
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8016764/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8016764/>
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8016764
>>
>> Thanks! Harold


From david.holmes at oracle.com  Wed Aug 28 19:09:04 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 29 Aug 2013 12:09:04 +1000
Subject: RFR JDK-8016764: JVM does not prohibit invokespecial in c.f.v
	51.0 that invokes default interface method in c.f.v 52.0
In-Reply-To: <521EA192.4060109@oracle.com>
References: <521E14C6.8030507@oracle.com> <521E9B47.9070409@oracle.com>
	<521EA192.4060109@oracle.com>
Message-ID: <521EAD40.8090404@oracle.com>

On 29/08/2013 11:19 AM, harold seigel wrote:
> Hi David,
>
> The removal of the two lines causes the _invokespecial case to fall
> through to the _invokestatic case.

I missed the fallthrough. So invokespecial and invokestatic are now 
handled the same.

> The _invokestatic case checks to see if _klass->major_version() is less
> than STATIC_METHOD_IN_INTERFACE_MAJOR_VERSION.  That is a comparison of
> class file versions.
>
> If klass->major_version() is less than 52 then the constantpool entry
> can only be a Methodref.
>
> Does that help clarify things?

Thanks.
David

> Thanks, Harold
>
> On 8/28/2013 8:52 PM, David Holmes wrote:
>> Hi Harold,
>>
>> On 29/08/2013 1:18 AM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this small fix for bug 8016764.  The change prevents class
>>> files of version 51 and lower from using invokespecial to call default
>>> interface methods that are in class files of version 52.
>>
>> I don't have much knowledge of the verifier but I don't see anything
>> that refers to the class file versions involved. Is it implicit in the
>> fact we got to this particular piece of code?
>>
>> Thanks,
>> David
>>
>>> The fix was tested with the JCK Lang and VM tests, ute tests, and some
>>> of the tests listed in the bug.
>>>
>>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8016764/
>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8016764/>
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8016764
>>>
>>> Thanks! Harold
>

From jiangli.zhou at oracle.com  Wed Aug 28 18:38:55 2013
From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com)
Date: Thu, 29 Aug 2013 01:38:55 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 2 new changesets
Message-ID: <20130829013901.CAE566238E@hg.openjdk.java.net>

Changeset: 1fedf3c7f923
Author:    bpittore
Date:      2013-08-28 14:44 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1fedf3c7f923

8023580: Add jtreg test for 8004051 and 8005722
Summary: Tests checks an assertion dealing with the number of args passed in registers
Reviewed-by: mseledtsov, kvn

+ test/compiler/8004051/Test8004051.java

Changeset: b1fb293d92c4
Author:    jiangli
Date:      2013-08-28 12:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b1fb293d92c4

Merge



From kamggg at gmail.com  Wed Aug 28 19:31:08 2013
From: kamggg at gmail.com (Keith McGuigan)
Date: Wed, 28 Aug 2013 22:31:08 -0400
Subject: S RFR: Lambda: verification error in generated lambda classes
In-Reply-To: <491B7272-B309-4193-BF8B-E7889441B6FB@oracle.com>
References: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
	<521E9A45.8040809@oracle.com>
	<491B7272-B309-4193-BF8B-E7889441B6FB@oracle.com>
Message-ID: <CAFUO74kYcSx5umWA_VY4Aq_R8UnHHcn3VaMsJ-N6qsuNKc4AtQ@mail.gmail.com>

I think it's ok as it is, if you need to check it in quick, but I agree
that this probably should be rewritten better to make the logic more
obvious.  Maybe separate clauses for reflection/lambda code?

    ((!is_MAI && !is_MLI) ||
    (is_MAI && VerifyReflectionBytecodes) ||
    (is_MLI && VerifyLambdaBytecodes))

Isn't this equivalent to:
  (!is_MAI || VerifyReflectionBytecodes) &&
  (!is_MLI || VerifyLambdaBytecodes)



On Wed, Aug 28, 2013 at 8:50 PM, Karen Kinnear <Karen.Kinnear at oracle.com>wrote:

> Thank you David. I agree, I was tempted to rewrite the entire method - in
> particular, in a debugger
> (so I didn't check the optimized code) we walk the entire && before we
> make the initial call - in this
> case the initial call would weed out more things faster potentially, so
> ... But I chose not to rewrite since
> they need this quickly and the shaking out would take quite a bit longer.
>
> thanks for the review,
> Karen
>
> On Aug 28, 2013, at 8:48 PM, David Holmes wrote:
>
> > Hi Karen,
> >
> > I found the boolean logic very hard to follow there - not sure if the
> refactoring helped or hindered :)
> >
> > But it looks okay.
> >
> > David
> >
> > On 29/08/2013 5:42 AM, Karen Kinnear wrote:
> >> Please review - lambda team needs this change to get in by tomorrow so
> >> they can push
> >> the (8010433) metafactory change which is waiting on the vm. Thanks.
> >>
> >>
> >> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
> >> http://bugs.sun.com/view_bug.do?bug_id=8023872
> >>
> >> Testing:
> >> The failure comes if you apply an early patch of 8010433 to the jdk and
> >> do not
> >> make the vm change. So testing included 4 binaries: master, newjdk,
> >> newvm, newjdkvm
> >>
> >> jtreg for SpinedBufferTest with various flags - these are the expected
> >> results below
> >> The key point is newjdk -Xverify: all fails
> >> newjdkvm -Xverify:all passes, but if you also turn on
> >> -XX:+VerifyLambdaBytecodes you see
> >>    the verification error
> >>
> >> 1. master
> >>  no flags: timed out
> >>  -Xverify:all: timed out
> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
> >>
> >> 2. newjdk
> >>  no flags: timed out
> >>  -Xverify:all
> >>    java.lang.BootstrapMethodError: call site initialization exception
> >> ... cause:
> >>      VerifyError: Bad invokespecial instruction: current class isn't
> >> assignable to reference class
> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
> >>
> >> 3. newvm
> >>   no flags: timed out
> >>   rerun.sh: -Xverify:all: passed
> >>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
> >>   -XX:+VerifyLambdaBytecodes: passed, didn't try verification
> >>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
> >>
> >> 4. newjdkvm
> >>  rerun.sh: no flags: passed
> >>  rerun.verify.sh: -Xverify:all: passed
> >>  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
> >>    Verification for java.util.streamIntPipeline$7$1$$Lambda$9 failed
> >>
> >> regression testing:
> >> newvm:
> >>   vm.quick.testlist - in progress
> >>   jtreg java/util/stream - in progress
> >>   jprt -stree . - in progress
> >>
> >> newvmjdk (Brian testing in lambda repo) - in progress
> >>
> >> thanks,
> >> Karen
> >>
>
>


-- 
- Keith McGuigan <keith.mcguigan at alumni.unh.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130828/43b4248c/attachment-0001.html 

From david.holmes at oracle.com  Wed Aug 28 20:31:34 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Thu, 29 Aug 2013 03:31:34 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 2 new changesets
Message-ID: <20130829033142.D353062391@hg.openjdk.java.net>

Changeset: 2b113b65a051
Author:    dholmes
Date:      2013-08-28 19:25 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2b113b65a051

8023900: [TESTBUG] Initial compact profile test groups need adjusting
Reviewed-by: dcubed, mchung, hseigel

! test/TEST.groups

Changeset: 54dfd798deaf
Author:    dholmes
Date:      2013-08-28 21:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/54dfd798deaf

Merge



From staffan.larsen at oracle.com  Thu Aug 29 01:26:00 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 29 Aug 2013 10:26:00 +0200
Subject: RFR: 8023720: setjmp/longjmp changes the process signal mask on
	OS X
In-Reply-To: <C0C4F10B-7450-4DA6-9428-7D9434186EEC@oracle.com>
References: <3F44268B-E81C-421C-BD52-6395876D7652@oracle.com>
	<C0C4F10B-7450-4DA6-9428-7D9434186EEC@oracle.com>
Message-ID: <D07A02CB-21C5-474B-B5C3-8F0DD8092AE0@oracle.com>

Can I have a second review for the Hotspot part of this change?

Thanks,
/Staffan

On 27 aug 2013, at 10:48, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> I have also made a fix for hotspot. I messed up the link in the last email so here are both webrevs.
> 
> jdk: http://cr.openjdk.java.net/~sla/8023786/webrev.00/
> hotspot: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
> 
> Thanks,
> /Staffan
> 
> On 27 aug 2013, at 10:41, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
>> The original conversation about this problem is here:  http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html 
>> 
>> In short, setjmp/longjmp on OS X messes up the signal mask and we should use _setjmp/_longjmp instead.
>> 
>> This change fixes two occurences in the jdk. There are a couple more in the client and hotspot areas which I will file followup bugs about.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>> 
>> Thanks,
>> /Staffan
> 


From rickard.backman at oracle.com  Thu Aug 29 01:56:37 2013
From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=)
Date: Thu, 29 Aug 2013 10:56:37 +0200
Subject: RFR: 8023720: setjmp/longjmp changes the process signal mask on
	OS X
In-Reply-To: <D07A02CB-21C5-474B-B5C3-8F0DD8092AE0@oracle.com>
References: <3F44268B-E81C-421C-BD52-6395876D7652@oracle.com>
	<C0C4F10B-7450-4DA6-9428-7D9434186EEC@oracle.com>
	<D07A02CB-21C5-474B-B5C3-8F0DD8092AE0@oracle.com>
Message-ID: <B345E066-ACAE-49E1-90ED-A6DAFA523AF1@oracle.com>

Looks good!

/R

On Aug 29, 2013, at 10:26 AM, Staffan Larsen wrote:

> Can I have a second review for the Hotspot part of this change?
> 
> Thanks,
> /Staffan
> 
> On 27 aug 2013, at 10:48, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
>> I have also made a fix for hotspot. I messed up the link in the last email so here are both webrevs.
>> 
>> jdk: http://cr.openjdk.java.net/~sla/8023786/webrev.00/
>> hotspot: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>> 
>> Thanks,
>> /Staffan
>> 
>> On 27 aug 2013, at 10:41, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>> 
>>> The original conversation about this problem is here:  http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html 
>>> 
>>> In short, setjmp/longjmp on OS X messes up the signal mask and we should use _setjmp/_longjmp instead.
>>> 
>>> This change fixes two occurences in the jdk. There are a couple more in the client and hotspot areas which I will file followup bugs about.
>>> 
>>> webrev: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>>> 
>>> Thanks,
>>> /Staffan
>> 
> 


From kevin.walls at oracle.com  Thu Aug 29 02:52:12 2013
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 29 Aug 2013 10:52:12 +0100
Subject: RFR 8019375: Internal symbol table size should be tunable.
In-Reply-To: <5217AFCF.1040200@oracle.com>
References: <52172CC0.30103@oracle.com> <5217AFCF.1040200@oracle.com>
Message-ID: <521F19CC.3020208@oracle.com>

On 23/08/13 19:54, Coleen Phillimore wrote:
>
> Hi Kevin,
>
> I'm sorry I didn't warn you but I think there are serviceability agent 
> changes with this change.   For some reason, I think the SA duplicates 
> code in the JVM for the symbol table.
>
> You might get away with only changing this line in 
> agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java
>
>     symbolTableSize = 
> db.lookupIntConstant("SymbolTable::symbol_table_size").intValue(); to 
> use SymbolTableSize.
>
> Then run the nsk.sajdi.testlist tests.
>
> Thanks,
> Coleen
>
> On 8/23/2013 5:34 AM, Kevin Walls wrote:
>> Hi,
>>
>> I'd like to get reviews on this change to make the size of the symbol 
>> table tunable.  This can be a performance benefit to some apps, i.e. 
>> when the symbol table becomes overloaded (see 
>> PrintStringTableStatistics output).
>>
>> This work here actually comes from Coleen.  I'm happy to take any 
>> further comments and update.
>>
>> http://cr.openjdk.java.net/~kevinw/8019375/webrev.01/
>> http://bugs.sun.com/view_bug.do?bug_id=8019375
>>
>> This uses SymbolTableSize as the tunable name.  (Another suggestion 
>> and possibile name, was PredictedMaxVMStrings to avoid talking 
>> explicity about the internal format.  Comments welcome!...)
>>
>> Thanks
>> Kevin
>

Thanks Coleen,  (and thanks Keith too!)

Yes, we have a getSymbolTableSize() accessor in 
agent/...../SymbolTable.java, though I don't see it ever being called, 
which must be why the SA still worked. 8-)

The SA does not have a size accessor for StringTable, I am wondering if 
we should remove this one too if it's never used.  Will test and reply 
again...

Thanks
Kevin

From david.holmes at oracle.com  Thu Aug 29 04:13:03 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 29 Aug 2013 21:13:03 +1000
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521E1D0D.80307@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
	<521C9F11.5010809@oracle.com> <521D486E.8090207@oracle.com>
	<521E1D0D.80307@oracle.com>
Message-ID: <521F2CBF.2090809@oracle.com>

On 29/08/2013 1:53 AM, Coleen Phillimore wrote:
> On 8/27/2013 8:46 PM, David Holmes wrote:
>> Thanks for the detailed explanation. It is frustrating that we keep
>> having to revisit these allocation routines.
>>
>> However it still seems to me that we don't need NO_EXCEPT on most of
>> our operator new definitions because they will never return NULL. This
>> is trivially so for things like:
>>
>>  void* StackObj::operator new(size_t size)     NOEXCEPT {
>> ShouldNotCallThis(); return 0; }
>> void* _ValueObj::operator new(size_t size)    NOEXCEPT {
>> ShouldNotCallThis(); return 0; }
>>
>> but also for anything that invokes vm_exit_out_of_memory directly or
>> indirectly.
>
> I don't think this is a good idea at all.   We want the constructor
> prologue to always check for null before calling the constructor. We
> will never throw C++ exceptions for these so all operator new's are
> NOEXCEPT.   These trivial examples would return zero rather than
> throwing if ShouldNotCallThis() is ifdef'ed out in product.   So, this
> example is either trivially wrong without NOEXCEPT or correct without
> NOEXCEPT.   It is safer code to make them all NOEXCEPT.

If the allocator can never return a NULL value then checking for NULL is 
completely redundant. We don't check our internal allocation routines 
for NULL returns where we know they abort on failure, so how is this any 
different ? AFAICS ShouldNotCallThis() is not ifdef'd out but if it were 
then yes this would fail - as would ifdef'ing out a 
vm_exit_out_of_memory in the other allocation routines.

> So really the only question is whether NOEXCEPT is better than
> throw().    throw() looks nicer because it's not a macro.  NOEXCEPT may
> be required for the future if that's required to conditionally add the
> noexcept keyword.
>
> Maybe we should use throw() for now and worry about the noexcept keyword
> if that becomes an issue.

It would be less ugly to use throw() but more intrusive in that it 
affects all the compilers. Plus I don't know what the benefit would be 
of moving from throw() to noexcept if they both mean the same thing?

> David, where are you removing spurious throw() expressions and why?

./share/vm/code/nmethod.cpp:void* nmethod::operator new(size_t size, int 
nmethod_size) throw () {

See:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-August/010526.html

and subsequent replies. The presence of throw() was considered an error 
at the time but now it seems not. I don't know if it has been removed in 
hotspot-compiler, or perhaps just in the staging repos for the ppc64 
changes.

Cheers,
David
------



> Thanks,
> Coleen
>
>>
>> David
>> -----
>>
>> On 27/08/2013 10:44 PM, Lois Foltan wrote:
>>>
>>> On 8/27/2013 7:31 AM, David Holmes wrote:
>>>> On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
>>>>> On 2013-08-27 04:41, David Holmes wrote:
>>>>>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>>>>>> Please review the following fix:
>>>>>>>
>>>>>>> Internal webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>>>>>
>>>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file
>>>>>>> produced &
>>>>>>>           runtime/6878713/Test6878713.sh fails on mac
>>>>>>>
>>>>>>>      bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>>>>
>>>>>>> Summary of fix:
>>>>>>>      On MacOS, currently Hotspot is built specifying the -fcheck-new
>>>>>>> command line option to the llvm-g++ compiler.
>>>>>>>      The -fcheck-new option directs the compiler to "check that the
>>>>>>> pointer returned by |operator new| is non-null
>>>>>>>       before attempting to modify the storage allocated." The
>>>>>>> clang++
>>>>>>> compiler does not support the
>>>>>>>       -fcheck-new option.  To obtain similiar functionality when
>>>>>>> building Hotspot with clang++, empty exception
>>>>>>>       throw() specifications must be added to all user-defined
>>>>>>> operator
>>>>>>> new()'s.
>>>>>>
>>>>>> We just spotted something related in the PPC64 port and were going
>>>>>> the
>>>>>> other way or removing these "spurious" throw() declarations.
>>>>>>
>>>>>> But this seems really ugly - is there really a need to specialize
>>>>>> this
>>>>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
>>>>>> honour the nothrow() semantics?
>>>>>>
>>>>>> That said I thought we already handled this using the "const
>>>>>> std::nothrow_t&  nothrow_constant" where needed? Our other
>>>>>> operator new
>>>>>> implementations shouldn't return NULL but will abort.
>>>>>>
>>>>>> So why do we need -fcheck-new or this empty throw() ?
>>>>>
>>>>> I guess that if the C++ compiler knows that operator new() will
>>>>> throw an
>>>>> exception if an allocation fails then it doesn't need to emit code to
>>>>> explicitly avoid calling the constructor.
>>>>
>>>> Yes that is what happens, but why do _we_ need it when ...
>>>>
>>>>> If we declare operator new() with an empty throw() we will also inform
>>>>> the compiler that new can't throw an exception and therefore the
>>>>> compiler needs to explicitly handle failed allocations.
>>>>
>>>> ... we have two kinds of operator new implementations (or at least we
>>>> _should_ only have two kinds):
>>>>
>>>> 1. Will abort on OOM (either ResourceArea exhaustion or Stack
>>>> exhaustion) and so never returns NULL
>>>> 2. Can return NULL and uses std::nothrow to indicate that
>>>>
>>>> So we should not need this if the nothrow is acting as I think it
>>>> should. Have we missed places where nothrow is needed? Do we have
>>>> errant operator new definitions unrelated to the allocation base
>>>> classes?
>>> Hi David,
>>>
>>> I think there may be some confusion about what std::nothrow_t is
>>> actually doing.  It provides a mechanism to overload operator new &
>>> delete in order to direct the compiler to prefer a function definition
>>> that also should contain an empty "throw()" specification.  Take for
>>> example the standard definition of the global ::operator new(). It
>>> actually looks like:
>>>
>>>   * void * operator new <a00960.html#a1414bcdb34c39ce82fc84bc8d5287966>
>>>     (std::size_t) throw (std::bad_alloc)
>>>   * void * operator new <a00960.html#a940b606c7824b4d5dd121199c277d629>
>>>     (std::size_t, const std::nothrow_t &) throw ()
>>>
>>> When the std::nothrow_t parameter is passed to the global ::operator
>>> new() the invoked function is the one that also contains an empty
>>> throw() specification.  It is due to this empty throw() specification
>>> that directs or triggers the C++ compiler to generate the detection of
>>> NULL constructor prologue.   Specifying only the std::nothrow_t
>>> parameter to a class member user-defined ::operator new() does not
>>> indicate to a C++ compiler that the function does not throw an
>>> exception.  According to the c++98 standard, a function that will throw
>>> no exceptions should be delcared with an empty "throw()" list
>>> specification.  When first experimenting with a fix, I did just try to
>>> overload Hotspot's user-defined operator new() with the std:nothrow_t
>>> parameter.  As expected, the mere presence of this parameter did not
>>> trigger the clang++ compiler to generate NULL detection constructor
>>> prologue code.  Unfortunately, probably due to legacy code, some C++
>>> compilers behave differently.  For example, I did confirm with Solaris
>>> C++ development, the Solaris C++ by default always generates constructor
>>> prologue code that detects NULL for class member user-defined operator
>>> new() even in a throw situation. G++ provides the -fcheck-new command
>>> line option.  It is due to these differences of behavior or Hotspot's
>>> build specification of -fcheck-new that has led us to believe that
>>> std::nothrow_t was providing something that it is not.
>>>
>>> That said, I would also prefer what you propose, deciding on two kinds
>>> of operator new()'s that can be defined.  I did examine all of the
>>> user-defined operator new()'s within the code and I determined that only
>>> a very small number possibly could not return NULL.  Given this,
>>> factored in with the historical reliance on -fcheck-new for the g++
>>> compilers, I decided the safe route for JDK 8 was to introduce the
>>> NOEXCEPT macro.
>>>
>>> Lois
>>>>
>>>> David
>>>> -----
>>>>
>>>>> The g++ man page states:
>>>>>
>>>>>         -fcheck-new
>>>>>             Check that the pointer returned by "operator new" is
>>>>> non-null before attempting to modify the storage allocated. This check
>>>>> is normally unnecessary because the C++ standard specifies that
>>>>>             "operator new" will only return 0 if it is declared
>>>>> throw(),
>>>>> in which case the compiler will always check the return value even
>>>>> without this option.  In all other cases, when "operator new"
>>>>>             has a non-empty exception specification, memory exhaustion
>>>>> is signalled by throwing "std::bad_alloc".  See also new (nothrow).
>>>>>
>>>>> /Mikael
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Tests:
>>>>>>>
>>>>>>>       Solaris: built fastdebug & product images
>>>>>>>       Linux: built fastdebug & product images
>>>>>>>       MacOS:  built fastdebug & product images using llvm-g++ - ran
>>>>>>> JTREG
>>>>>>>                      built fastdebug & product images using
>>>>>>> clang++ -
>>>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>>>>>       Windows:  built fastdebug & product images with VS2010
>>>>>>>
>>>
>

From david.holmes at oracle.com  Thu Aug 29 04:16:15 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 29 Aug 2013 21:16:15 +1000
Subject: RFR JDK-8022407 (round 2) sun/misc/CopyMemory.java fails with
	SIGSEGV in Unsafe_SetByte+0x35
In-Reply-To: <521E39DB.1050901@oracle.com>
References: <521CD14D.5040809@oracle.com> <521E39DB.1050901@oracle.com>
Message-ID: <521F2D7F.5030001@oracle.com>

Hi Lois,

Is this still needed:

  142     PCH_FLAG/unsafe.o = $(PCH_FLAG/NO_PCH)

given you no longer use -O0 ?

Thanks,
David

On 29/08/2013 3:56 AM, Lois Foltan wrote:
>
> Please review the updated webrev:
>      open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407.2/
>
> Bug:
>      bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>
> Summary of fix:
>
>      The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++
> compiler, exhibited a compiler
>      optimization issue when prims/unsafe.cpp was compiled at the
> default -Os level. As a work around
>      fix, knock the optimization level down down to -O1.
>
> Tests: MacOS: built fastdebug & product images using clang++ (ran JTREG
> & vm.quick.testlist)
>            built using llvm-g++ to verifyprims/unsafe.cpp remained
> compiled at -Os
>
> Thank you, Lois
>
>

From karen.kinnear at oracle.com  Thu Aug 29 04:55:31 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 29 Aug 2013 07:55:31 -0400
Subject: RFR 8019375: Internal symbol table size should be tunable.
In-Reply-To: <52172CC0.30103@oracle.com>
References: <52172CC0.30103@oracle.com>
Message-ID: <AF394507-7A6D-447A-A605-AA264A0BB6F1@oracle.com>

Kevin,

Let's talk - I was serious about not asking customers to give values that tune our internal metadata sizes -
we are potentially moving to different types of metadata or combining symbols with other things -- please
modify to get a PredictedMaxVMStrings (other names welcome) - but to get a size from the customers that
we then adopt metadata heuristics to.

thanks,
Karen

On Aug 23, 2013, at 5:34 AM, Kevin Walls wrote:

> Hi,
> 
> I'd like to get reviews on this change to make the size of the symbol table tunable.  This can be a performance benefit to some apps, i.e. when the symbol table becomes overloaded (see PrintStringTableStatistics output).
> 
> This work here actually comes from Coleen.  I'm happy to take any further comments and update.
> 
> http://cr.openjdk.java.net/~kevinw/8019375/webrev.01/
> http://bugs.sun.com/view_bug.do?bug_id=8019375
> 
> This uses SymbolTableSize as the tunable name.  (Another suggestion and possibile name, was PredictedMaxVMStrings to avoid talking explicity about the internal format.  Comments welcome!...)
> 
> Thanks
> Kevin


From lois.foltan at oracle.com  Thu Aug 29 05:01:31 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 29 Aug 2013 08:01:31 -0400
Subject: RFR JDK-8022407 (round 2) sun/misc/CopyMemory.java fails with
	SIGSEGV in Unsafe_SetByte+0x35
In-Reply-To: <521F2D7F.5030001@oracle.com>
References: <521CD14D.5040809@oracle.com> <521E39DB.1050901@oracle.com>
	<521F2D7F.5030001@oracle.com>
Message-ID: <521F381B.5090005@oracle.com>


On 8/29/2013 7:16 AM, David Holmes wrote:
> Hi Lois,
>
> Is this still needed:
>
>  142     PCH_FLAG/unsafe.o = $(PCH_FLAG/NO_PCH)
>
> given you no longer use -O0 ?
Hi David,
Yes, I believe so but this might be a cautionary change on my part. I 
read the comment to imply that Clang does not support a precompiled 
header compiled with an optimization level that is different than the 
one used to compile the actual C++ file, this is why I chose to add 
unsafe.o.
Lois

> Thanks,
> David
>
> On 29/08/2013 3:56 AM, Lois Foltan wrote:
>>
>> Please review the updated webrev:
>>      open webrev at 
>> http://cr.openjdk.java.net/~hseigel/bug_jdk8022407.2/
>>
>> Bug:
>>      bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>
>> Summary of fix:
>>
>>      The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++
>> compiler, exhibited a compiler
>>      optimization issue when prims/unsafe.cpp was compiled at the
>> default -Os level. As a work around
>>      fix, knock the optimization level down down to -O1.
>>
>> Tests: MacOS: built fastdebug & product images using clang++ (ran JTREG
>> & vm.quick.testlist)
>>            built using llvm-g++ to verifyprims/unsafe.cpp remained
>> compiled at -Os
>>
>> Thank you, Lois
>>
>>


From kirk at kodewerk.com  Thu Aug 29 05:44:57 2013
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Thu, 29 Aug 2013 14:44:57 +0200
Subject: RFR 8019375: Internal symbol table size should be tunable.
In-Reply-To: <AF394507-7A6D-447A-A605-AA264A0BB6F1@oracle.com>
References: <52172CC0.30103@oracle.com>
	<AF394507-7A6D-447A-A605-AA264A0BB6F1@oracle.com>
Message-ID: <DA2302EF-EBCA-47E5-AD88-8AF8C3DC0AF8@kodewerk.com>

Hi all,

I'm inclined to believe that there are performance benefits to be gained by being able to get statistics and then use those statistics to better size both the dictionary and the String table. The fact that we've not had ready access to these stats and settings in the field has at times compromised tuning efforts. The Code Cache is another example of where an auto-tunable hasn't quite worked out and that the ability to obtain measures and make adjustments would have been invaluable.

Kind regards,
Kirk Pepperdine

On 2013-08-29, at 1:55 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:

> Kevin,
> 
> Let's talk - I was serious about not asking customers to give values that tune our internal metadata sizes -
> we are potentially moving to different types of metadata or combining symbols with other things -- please
> modify to get a PredictedMaxVMStrings (other names welcome) - but to get a size from the customers that
> we then adopt metadata heuristics to.
> 
> thanks,
> Karen
> 
> On Aug 23, 2013, at 5:34 AM, Kevin Walls wrote:
> 
>> Hi,
>> 
>> I'd like to get reviews on this change to make the size of the symbol table tunable.  This can be a performance benefit to some apps, i.e. when the symbol table becomes overloaded (see PrintStringTableStatistics output).
>> 
>> This work here actually comes from Coleen.  I'm happy to take any further comments and update.
>> 
>> http://cr.openjdk.java.net/~kevinw/8019375/webrev.01/
>> http://bugs.sun.com/view_bug.do?bug_id=8019375
>> 
>> This uses SymbolTableSize as the tunable name.  (Another suggestion and possibile name, was PredictedMaxVMStrings to avoid talking explicity about the internal format.  Comments welcome!...)
>> 
>> Thanks
>> Kevin
> 


From lois.foltan at oracle.com  Thu Aug 29 06:15:08 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 29 Aug 2013 09:15:08 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F2CBF.2090809@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
	<521C9F11.5010809@oracle.com> <521D486E.8090207@oracle.com>
	<521E1D0D.80307@oracle.com> <521F2CBF.2090809@oracle.com>
Message-ID: <521F495C.9030900@oracle.com>


On 8/29/2013 7:13 AM, David Holmes wrote:
> On 29/08/2013 1:53 AM, Coleen Phillimore wrote:
>> On 8/27/2013 8:46 PM, David Holmes wrote:
>>> Thanks for the detailed explanation. It is frustrating that we keep
>>> having to revisit these allocation routines.
>>>
>>> However it still seems to me that we don't need NO_EXCEPT on most of
>>> our operator new definitions because they will never return NULL. This
>>> is trivially so for things like:
>>>
>>>  void* StackObj::operator new(size_t size)     NOEXCEPT {
>>> ShouldNotCallThis(); return 0; }
>>> void* _ValueObj::operator new(size_t size)    NOEXCEPT {
>>> ShouldNotCallThis(); return 0; }
>>>
>>> but also for anything that invokes vm_exit_out_of_memory directly or
>>> indirectly.
>>
>> I don't think this is a good idea at all.   We want the constructor
>> prologue to always check for null before calling the constructor. We
>> will never throw C++ exceptions for these so all operator new's are
>> NOEXCEPT.   These trivial examples would return zero rather than
>> throwing if ShouldNotCallThis() is ifdef'ed out in product. So, this
>> example is either trivially wrong without NOEXCEPT or correct without
>> NOEXCEPT.   It is safer code to make them all NOEXCEPT.
>
> If the allocator can never return a NULL value then checking for NULL 
> is completely redundant. 
Hi David,
We do have allocators that can return a NULL value, like 
MetaSpace::allocate(), Chunk's operator new(), etc.  Both demonstrating 
the return of NULL in the two bug reports.

> We don't check our internal allocation routines for NULL returns where 
> we know they abort on failure, so how is this any different ? 
Actually we have been checking NULL, it's just that the C++ compiler's 
have been implicitly checking NULL for us.  Solaris C++ generates by 
default NULL detection constructor prologue code for user-defined class 
member operator new() even in a throw situation. For gcc we specify 
-fcheck-new.  So whether or not we explicitly direct the compiler to 
check via an empty "throw()" specification or not, it's still being 
done.  So why should we check now?  Because we have a C++ compiler, 
clang, that adheres to the standard and doesn't support -fcheck-new.  It 
wants to be explicitly told.

> AFAICS ShouldNotCallThis() is not ifdef'd out but if it were then yes 
> this would fail - as would ifdef'ing out a vm_exit_out_of_memory in 
> the other allocation routines.
>> So really the only question is whether NOEXCEPT is better than
>> throw().    throw() looks nicer because it's not a macro. NOEXCEPT may
>> be required for the future if that's required to conditionally add the
>> noexcept keyword.
>>
>> Maybe we should use throw() for now and worry about the noexcept keyword
>> if that becomes an issue.
>
> It would be less ugly to use throw() but more intrusive in that it 
> affects all the compilers. Plus I don't know what the benefit would be 
> of moving from throw() to noexcept if they both mean the same thing?
I believe the c++11 standard obsolesces "throw()" in favor of noexcept 
keyword.  However, I can't imagine that a compiler would completely 
obsolesce it, I can image there will be a mode to still support "throw()".

Lois
>
>> David, where are you removing spurious throw() expressions and why?
>
> ./share/vm/code/nmethod.cpp:void* nmethod::operator new(size_t size, 
> int nmethod_size) throw () {
>
> See:
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-August/010526.html 
>
>
> and subsequent replies. The presence of throw() was considered an 
> error at the time but now it seems not. I don't know if it has been 
> removed in hotspot-compiler, or perhaps just in the staging repos for 
> the ppc64 changes.
>
> Cheers,
> David
> ------
>
>
>
>> Thanks,
>> Coleen
>>
>>>
>>> David
>>> -----
>>>
>>> On 27/08/2013 10:44 PM, Lois Foltan wrote:
>>>>
>>>> On 8/27/2013 7:31 AM, David Holmes wrote:
>>>>> On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
>>>>>> On 2013-08-27 04:41, David Holmes wrote:
>>>>>>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>>>>>>> Please review the following fix:
>>>>>>>>
>>>>>>>> Internal webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>>>>>>
>>>>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file
>>>>>>>> produced &
>>>>>>>>           runtime/6878713/Test6878713.sh fails on mac
>>>>>>>>
>>>>>>>>      bug links at: 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8021954
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>>>>>
>>>>>>>> Summary of fix:
>>>>>>>>      On MacOS, currently Hotspot is built specifying the 
>>>>>>>> -fcheck-new
>>>>>>>> command line option to the llvm-g++ compiler.
>>>>>>>>      The -fcheck-new option directs the compiler to "check that 
>>>>>>>> the
>>>>>>>> pointer returned by |operator new| is non-null
>>>>>>>>       before attempting to modify the storage allocated." The
>>>>>>>> clang++
>>>>>>>> compiler does not support the
>>>>>>>>       -fcheck-new option.  To obtain similiar functionality when
>>>>>>>> building Hotspot with clang++, empty exception
>>>>>>>>       throw() specifications must be added to all user-defined
>>>>>>>> operator
>>>>>>>> new()'s.
>>>>>>>
>>>>>>> We just spotted something related in the PPC64 port and were going
>>>>>>> the
>>>>>>> other way or removing these "spurious" throw() declarations.
>>>>>>>
>>>>>>> But this seems really ugly - is there really a need to specialize
>>>>>>> this
>>>>>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
>>>>>>> honour the nothrow() semantics?
>>>>>>>
>>>>>>> That said I thought we already handled this using the "const
>>>>>>> std::nothrow_t&  nothrow_constant" where needed? Our other
>>>>>>> operator new
>>>>>>> implementations shouldn't return NULL but will abort.
>>>>>>>
>>>>>>> So why do we need -fcheck-new or this empty throw() ?
>>>>>>
>>>>>> I guess that if the C++ compiler knows that operator new() will
>>>>>> throw an
>>>>>> exception if an allocation fails then it doesn't need to emit 
>>>>>> code to
>>>>>> explicitly avoid calling the constructor.
>>>>>
>>>>> Yes that is what happens, but why do _we_ need it when ...
>>>>>
>>>>>> If we declare operator new() with an empty throw() we will also 
>>>>>> inform
>>>>>> the compiler that new can't throw an exception and therefore the
>>>>>> compiler needs to explicitly handle failed allocations.
>>>>>
>>>>> ... we have two kinds of operator new implementations (or at least we
>>>>> _should_ only have two kinds):
>>>>>
>>>>> 1. Will abort on OOM (either ResourceArea exhaustion or Stack
>>>>> exhaustion) and so never returns NULL
>>>>> 2. Can return NULL and uses std::nothrow to indicate that
>>>>>
>>>>> So we should not need this if the nothrow is acting as I think it
>>>>> should. Have we missed places where nothrow is needed? Do we have
>>>>> errant operator new definitions unrelated to the allocation base
>>>>> classes?
>>>> Hi David,
>>>>
>>>> I think there may be some confusion about what std::nothrow_t is
>>>> actually doing.  It provides a mechanism to overload operator new &
>>>> delete in order to direct the compiler to prefer a function definition
>>>> that also should contain an empty "throw()" specification. Take for
>>>> example the standard definition of the global ::operator new(). It
>>>> actually looks like:
>>>>
>>>>   * void * operator new 
>>>> <a00960.html#a1414bcdb34c39ce82fc84bc8d5287966>
>>>>     (std::size_t) throw (std::bad_alloc)
>>>>   * void * operator new 
>>>> <a00960.html#a940b606c7824b4d5dd121199c277d629>
>>>>     (std::size_t, const std::nothrow_t &) throw ()
>>>>
>>>> When the std::nothrow_t parameter is passed to the global ::operator
>>>> new() the invoked function is the one that also contains an empty
>>>> throw() specification.  It is due to this empty throw() specification
>>>> that directs or triggers the C++ compiler to generate the detection of
>>>> NULL constructor prologue.   Specifying only the std::nothrow_t
>>>> parameter to a class member user-defined ::operator new() does not
>>>> indicate to a C++ compiler that the function does not throw an
>>>> exception.  According to the c++98 standard, a function that will 
>>>> throw
>>>> no exceptions should be delcared with an empty "throw()" list
>>>> specification.  When first experimenting with a fix, I did just try to
>>>> overload Hotspot's user-defined operator new() with the std:nothrow_t
>>>> parameter.  As expected, the mere presence of this parameter did not
>>>> trigger the clang++ compiler to generate NULL detection constructor
>>>> prologue code.  Unfortunately, probably due to legacy code, some C++
>>>> compilers behave differently.  For example, I did confirm with Solaris
>>>> C++ development, the Solaris C++ by default always generates 
>>>> constructor
>>>> prologue code that detects NULL for class member user-defined operator
>>>> new() even in a throw situation. G++ provides the -fcheck-new command
>>>> line option.  It is due to these differences of behavior or Hotspot's
>>>> build specification of -fcheck-new that has led us to believe that
>>>> std::nothrow_t was providing something that it is not.
>>>>
>>>> That said, I would also prefer what you propose, deciding on two kinds
>>>> of operator new()'s that can be defined.  I did examine all of the
>>>> user-defined operator new()'s within the code and I determined that 
>>>> only
>>>> a very small number possibly could not return NULL.  Given this,
>>>> factored in with the historical reliance on -fcheck-new for the g++
>>>> compilers, I decided the safe route for JDK 8 was to introduce the
>>>> NOEXCEPT macro.
>>>>
>>>> Lois
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> The g++ man page states:
>>>>>>
>>>>>>         -fcheck-new
>>>>>>             Check that the pointer returned by "operator new" is
>>>>>> non-null before attempting to modify the storage allocated. This 
>>>>>> check
>>>>>> is normally unnecessary because the C++ standard specifies that
>>>>>>             "operator new" will only return 0 if it is declared
>>>>>> throw(),
>>>>>> in which case the compiler will always check the return value even
>>>>>> without this option.  In all other cases, when "operator new"
>>>>>>             has a non-empty exception specification, memory 
>>>>>> exhaustion
>>>>>> is signalled by throwing "std::bad_alloc".  See also new (nothrow).
>>>>>>
>>>>>> /Mikael
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Tests:
>>>>>>>>
>>>>>>>>       Solaris: built fastdebug & product images
>>>>>>>>       Linux: built fastdebug & product images
>>>>>>>>       MacOS:  built fastdebug & product images using llvm-g++ - 
>>>>>>>> ran
>>>>>>>> JTREG
>>>>>>>>                      built fastdebug & product images using
>>>>>>>> clang++ -
>>>>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>>>>>>       Windows:  built fastdebug & product images with VS2010
>>>>>>>>
>>>>
>>


From staffan.larsen at oracle.com  Thu Aug 29 06:40:34 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Thu, 29 Aug 2013 13:40:34 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8023720: (hotspot) setjmp/longjmp changes
	the process signal mask on OS X
Message-ID: <20130829134040.70E58623A4@hg.openjdk.java.net>

Changeset: cc56f122f3f7
Author:    sla
Date:      2013-08-29 11:05 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cc56f122f3f7

8023720: (hotspot) setjmp/longjmp changes the process signal mask on OS X
Reviewed-by: dholmes, rbackman

! src/os/posix/vm/os_posix.cpp


From thomas.schatzl at oracle.com  Thu Aug 29 07:28:00 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 29 Aug 2013 16:28:00 +0200
Subject: [Fwd: Re: RFR (M/L): 8010722 assert: failed: heap size is too big
	for compressed oops]
Message-ID: <1377786480.4272.12.camel@cirrus>

Hi all,

  forwarding the RFR for 8010722 here too as it contains changes on
parts of the runtime too (argument processing, large page
initialization), and you might be interested.

Note that the current webrev is
http://cr.openjdk.java.net/~tschatzl/8010722/webrev.3

Sorry for not thinking about cc'ing here earlier,
  Thomas

-------- Forwarded Message --------
> From: Thomas Schatzl <thomas.schatzl at oracle.com>
> To: hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR (M/L): 8010722 assert: failed: heap size is too big
> for compressed oops
> Date: Wed, 28 Aug 2013 15:32:46 +0200
> 
> Hi all,
> 
> On Tue, 2013-05-14 at 16:37 +0200, Thomas Schatzl wrote:
> > Hi all,
> > 
> JIRA:
> > https://jbs.oracle.com/bugs/browse/JDK-8010722
> 
>  can I have reviews for the following change?
> 
> > 
> > In argument processing related to ergonomically determining compressed
> > oops use, there were a few use-before-set issues leading to crashes that
> > this fix tries to resolve.
> > 
> > bugs.sun.com
> > http://bugs.sun.com/view_bug.do?bug_id=8010722
> > 
> > JIRA:
> > https://jbs.oracle.com/bugs/browse/JDK-8010722
> > 
> > webrev:
> > http://cr.openjdk.java.net/~tschatzl/8010722/webrev.1/
> 
> There is a new webrev at
> http://cr.openjdk.java.net/~tschatzl/8010722/webrev.2 ; this has become
> necessary after the changes in CR 8007074 (Stefan K's large pages
> changes) and CR 8003424 from Harold.
> 
> Particularly the latter changed how the class metadata space is
> allocated, removing a lot of additional checking and alignment issues.
> 
> However the core issue still persists, the maximum heap size for
> compressed oops is calculated wrongly as the NULL page is not properly
> accounted for.
> 
> testing:
> jprt, jprt test cases
> 
> Thomas
> 
> > Here's a walkthrough of the changes:
> > 
> > As mentioned, the cause of this CR is that ergonomics for determining
> > the maximum java heap size usable for compressed oops uses variables
> > that are later changed ergonomically.
> > 
> > It is best to look at the changes beginning from
> > Arguments::set_ergonomics_flags(): the idea of this change is to avoid
> > later overflow, so the change tries to conservatively estimate sizes of
> > the non-java heap parts. The complication is that not even the later
> > effective alignment of these heap parts has been determined at this
> > point.
> > 
> > So the change first calculates the maximum possible heap alignment by
> > calling set_max_heap_alignment(); this size is influenced by OS page
> > sizes, so the change needs to initialize large pages by calling
> > os::large_page_init() in Arguments::parse(), before the call to
> > set_ergonomics_flags(). The maximum possible alignment is then
> > calculated by asking the active GC for its maximum alignment, as at this
> > point the GC has already been determined, the maximum page size, and
> > other requirements, like alignment for card table size etc.
> > 
> > Now the code can calculate the conservative estimate for actual maximum
> > heap for compressed oops used in set_use_compressed_oops(), by
> > subtracting the conservatively aligned sizes of the other heap parts.
> > (In Arguments::max_heap_for_compressed_oops()) The result is the maximum
> > possible heap that can use compressed oops, minus the aligned metaspace
> > size, minus the aligned null page size.
> > 
> > There is another circular dependency problem here, the metaspace size itself is later ergonomically sized; the change fixes this problem by anticipating that in Arguments::max_heap_for_compressed_oops(), using the same predicate for determining whether to ergonomically size it or not [this is CR8009778 I think].
> > 
> > The other changes are straightforward: the os_* changes result from that
> > large page initialization must be done earlier now; the changes in the
> > collectors themselves are simply about providing the collector's maximum
> > alignment. The change in Universe::reserve_heap() contains one assertion that checks whether the conservative estimate for alignment has been conservative enough earlier.
> > 
> > The test case tests test cases from the CR that work now, and additional
> > border cases related to ergonomically deciding heap size for compressed
> > oops.
> > 
> > One side effect of this change is that the ergonomically determined heap size is slighly smaller now (so that it always fits :).
> > 
> > Thanks,
> >   Thomas
> > 
> > 
> > 
> > 
> > 
> 
> 



From christian.thalinger at oracle.com  Thu Aug 29 09:18:27 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 29 Aug 2013 09:18:27 -0700
Subject: RFR JDK-8022407 sun/misc/CopyMemory.java fails with SIGSEGV in
	Unsafe_SetByte+0x35
In-Reply-To: <521E3A4C.5070603@oracle.com>
References: <521BFA78.9070908@oracle.com> <521CD14D.5040809@oracle.com>
	<5CDAD4D1-5A6C-45EC-AAF3-4CB09FD76344@oracle.com>
	<521D005D.4050004@oracle.com> <521D0673.6070106@oracle.com>
	<E2EB7082-EC20-4635-B15A-BDF9340C7494@oracle.com>
	<521E3A4C.5070603@oracle.com>
Message-ID: <29557750-EEEA-4C9E-98F2-639341235E99@oracle.com>

Thanks.  -- Chris

On Aug 28, 2013, at 10:58 AM, Lois Foltan <lois.foltan at oracle.com> wrote:

> Hi Christian,
> 
> Thanks for the review.  I completed the change to only knock the optimization level  down to -O1 for the file prims/unsafe.cpp.
> 
> Lois
> 
> On 8/27/2013 9:15 PM, Christian Thalinger wrote:
>> On Aug 27, 2013, at 1:05 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>> 
>>> On 08/27/2013 03:39 PM, Lois Foltan wrote:
>>>> On 8/27/2013 1:29 PM, Christian Thalinger wrote:
>>>>> On Aug 27, 2013, at 9:18 AM, Lois Foltan <lois.foltan at oracle.com> wrote:
>>>>> 
>>>>>> Please review the following fix:
>>>>>>    open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407/
>>>>>> 
>>>>>> Bug:
>>>>>>    bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>>>>> 
>>>>>> Summary of fix:
>>>>>> 
>>>>>> The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++ compiler, exhibited a compiler optimization issue when prims/unsafe.cpp was compiled at the default -Os level. As a work around fix, knock the optimization level down down to -O0.
>>>>> Why are we lowering to -O0 when you state in the bug report that -O1 also works?  What is the code that breaks?
>>>>> 
>>>>> -- Chris
>>>> Hi Chris,
>>>> The convention within make/bsd/makefiles/gcc.make indicated that historically files that exhibited C++ compiler optimization issues were knocked down to /NOOPT or -O0.  I did also check with Coleen to make sure that prims/unsafe.cpp was not a performance critical file.
>>> So my advice was that it wasn't performance critical - because it's mostly calls from Java.  Except for maybe the anonymous class functions.  If you disagree, let us know.
>> I agree.  Most of the (performance critical) Unsafe methods are intrinsified anyway but why waste computing cycles and more importantly bytes (in object size) if we don't have to.
>> 
>> -- Chris
>> 
>>> Coleen
>>> 
>>>> -O1 does add some optimizations on top of -O0 but not inlining.  I will recheck testing with -O1 to confirm and change unsafe.cpp's optimization level to -O1 if testing yields good results.
>>>> 
>>>> I suspect the optimization problem is in unsafe.cpp's definition of Unsafe_GetNativeByte.  I had left off tracking it at that level and certainly will not close the JDK bug until I can narrow in further and hopefully report to the clang compiler team.
>>>> 
>>>> Thanks,
>>>> Lois
>>>>>> Tests:
>>>>>>    MacOS: built fastdebug & product images using clang++ (ran JTREG & vm.quick.testlist)
>>>>>>                   built using llvm-g++ to verify prims/unsafe.cpp remained compiled at -Os
>>>>>> 
>>>>>> Thank you,
>>>>>> Lois
>>>>>> 
>>>>>> 
> 


From harold.seigel at oracle.com  Thu Aug 29 09:56:17 2013
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Thu, 29 Aug 2013 16:56:17 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8016764: JVM does not prohibit
	invokespecial in c.f.v 51.0 that invokes default interface
	method in c.f.v 52.0
Message-ID: <20130829165623.14872623C2@hg.openjdk.java.net>

Changeset: 76482cbba706
Author:    hseigel
Date:      2013-08-29 10:33 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/76482cbba706

8016764: JVM does not prohibit invokespecial in c.f.v 51.0 that invokes default interface method in c.f.v 52.0
Summary: Check cfv before allowing invokespecial call to default method.
Reviewed-by: kamg, acorn, dholmes

! src/share/vm/classfile/verifier.cpp


From Karen.Kinnear at oracle.com  Thu Aug 29 10:29:50 2013
From: Karen.Kinnear at oracle.com (Karen Kinnear)
Date: Thu, 29 Aug 2013 13:29:50 -0400
Subject: S RFR: Lambda: verification error in generated lambda classes
In-Reply-To: <CAFUO74kYcSx5umWA_VY4Aq_R8UnHHcn3VaMsJ-N6qsuNKc4AtQ@mail.gmail.com>
References: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
	<521E9A45.8040809@oracle.com>
	<491B7272-B309-4193-BF8B-E7889441B6FB@oracle.com>
	<CAFUO74kYcSx5umWA_VY4Aq_R8UnHHcn3VaMsJ-N6qsuNKc4AtQ@mail.gmail.com>
Message-ID: <8BA6AF53-D39D-4821-8D63-E936FA4592B2@oracle.com>

Keith, David,

Many thanks for the suggestions. I think Keith's proposal is much simpler to read. I did
a name change as well to hopefully make this more obvious.

webrev.02: 
> >> webrev: http://cr.openjdk.java.net/~acorn/8023872.02/webrev/
> >> http://bugs.sun.com/view_bug.do?bug_id=8023872

I redid the manual testing, and the longer tests are in progress again.

thanks,
Karen

On Aug 28, 2013, at 10:31 PM, Keith McGuigan wrote:

> I think it's ok as it is, if you need to check it in quick, but I agree that this probably should be rewritten better to make the logic more obvious.  Maybe separate clauses for reflection/lambda code?
> 
>     ((!is_MAI && !is_MLI) ||
>     (is_MAI && VerifyReflectionBytecodes) ||
>     (is_MLI && VerifyLambdaBytecodes)) 
> 
> Isn't this equivalent to:
>   (!is_MAI || VerifyReflectionBytecodes) &&
>   (!is_MLI || VerifyLambdaBytecodes)
> 
> 
> 
> On Wed, Aug 28, 2013 at 8:50 PM, Karen Kinnear <Karen.Kinnear at oracle.com> wrote:
> Thank you David. I agree, I was tempted to rewrite the entire method - in particular, in a debugger
> (so I didn't check the optimized code) we walk the entire && before we make the initial call - in this
> case the initial call would weed out more things faster potentially, so ... But I chose not to rewrite since
> they need this quickly and the shaking out would take quite a bit longer.
> 
> thanks for the review,
> Karen
> 
> On Aug 28, 2013, at 8:48 PM, David Holmes wrote:
> 
> > Hi Karen,
> >
> > I found the boolean logic very hard to follow there - not sure if the refactoring helped or hindered :)
> >
> > But it looks okay.
> >
> > David
> >
> > On 29/08/2013 5:42 AM, Karen Kinnear wrote:
> >> Please review - lambda team needs this change to get in by tomorrow so
> >> they can push
> >> the (8010433) metafactory change which is waiting on the vm. Thanks.
> >>
> >>
> >> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
> >> http://bugs.sun.com/view_bug.do?bug_id=8023872
> >>
> >> Testing:
> >> The failure comes if you apply an early patch of 8010433 to the jdk and
> >> do not
> >> make the vm change. So testing included 4 binaries: master, newjdk,
> >> newvm, newjdkvm
> >>
> >> jtreg for SpinedBufferTest with various flags - these are the expected
> >> results below
> >> The key point is newjdk -Xverify: all fails
> >> newjdkvm -Xverify:all passes, but if you also turn on
> >> -XX:+VerifyLambdaBytecodes you see
> >>    the verification error
> >>
> >> 1. master
> >>  no flags: timed out
> >>  -Xverify:all: timed out
> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
> >>
> >> 2. newjdk
> >>  no flags: timed out
> >>  -Xverify:all
> >>    java.lang.BootstrapMethodError: call site initialization exception
> >> ... cause:
> >>      VerifyError: Bad invokespecial instruction: current class isn't
> >> assignable to reference class
> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
> >>
> >> 3. newvm
> >>   no flags: timed out
> >>   rerun.sh: -Xverify:all: passed
> >>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
> >>   -XX:+VerifyLambdaBytecodes: passed, didn't try verification
> >>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
> >>
> >> 4. newjdkvm
> >>  rerun.sh: no flags: passed
> >>  rerun.verify.sh: -Xverify:all: passed
> >>  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
> >>    Verification for java.util.streamIntPipeline$7$1$$Lambda$9 failed
> >>
> >> regression testing:
> >> newvm:
> >>   vm.quick.testlist - in progress
> >>   jtreg java/util/stream - in progress
> >>   jprt -stree . - in progress
> >>
> >> newvmjdk (Brian testing in lambda repo) - in progress
> >>
> >> thanks,
> >> Karen
> >>
> 
> 
> 
> 
> -- 
> - Keith McGuigan <keith.mcguigan at alumni.unh.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/9ebac478/attachment.html 

From zhengyu.gu at oracle.com  Thu Aug 29 10:52:50 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Thu, 29 Aug 2013 13:52:50 -0400
Subject: RFR: 6991327 : using -Xprof trigger native memory leak
Message-ID: <521F8A72.3080609@oracle.com>

The is a simple fix for memory leak.

FlatProfiler::record_thread_tick allocates array for JavaThread list, 
but never free it.


External bug: http://bugs.sun.com/view_bug.do?bug_id=6991327
Internal bug: https://bugs.openjdk.java.net/browse/JDK-6991327
Webrev: http://cr.openjdk.java.net/~zgu/6991327/webrev.00/ 
<http://cr.openjdk.java.net/%7Ezgu/6991327/webrev.00/>

Test:
   Ran test case (2) on bug report with NMT detail tracking on Linux 32, 
diff report clearly shows memory leak at 
FlatProfiler::record_thread_tick().  pmap also shows total memory grows 
continuously.

   With the fix, the call site no longer shows on diff report, and there 
are not obviously memory leaks on the report. pmap shows total memory 
stops growing after a while.

Sanity check:
   Passed JPRT with -Xprof flag

Thanks,

-Zhengyu


From kamggg at gmail.com  Thu Aug 29 11:02:26 2013
From: kamggg at gmail.com (Keith McGuigan)
Date: Thu, 29 Aug 2013 14:02:26 -0400
Subject: S RFR: Lambda: verification error in generated lambda classes
In-Reply-To: <8BA6AF53-D39D-4821-8D63-E936FA4592B2@oracle.com>
References: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
	<521E9A45.8040809@oracle.com>
	<491B7272-B309-4193-BF8B-E7889441B6FB@oracle.com>
	<CAFUO74kYcSx5umWA_VY4Aq_R8UnHHcn3VaMsJ-N6qsuNKc4AtQ@mail.gmail.com>
	<8BA6AF53-D39D-4821-8D63-E936FA4592B2@oracle.com>
Message-ID: <CAFUO74=K1qZF7vu+ewdXcZpKxvbiS47uEHynMbsQX0kkjmutYg@mail.gmail.com>

I think there's an extra set of parenthesis that isn't needed, but other
than that, thanks, looks good!


On Thu, Aug 29, 2013 at 1:29 PM, Karen Kinnear <Karen.Kinnear at oracle.com>wrote:

> Keith, David,
>
> Many thanks for the suggestions. I think Keith's proposal is much simpler
> to read. I did
> a name change as well to hopefully make this more obvious.
>
> webrev.02:
>
> >> webrev: http://cr.openjdk.java.net/~acorn/8023872.02/webrev/
>> >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>>
>
> I redid the manual testing, and the longer tests are in progress again.
>
> thanks,
> Karen
>
> On Aug 28, 2013, at 10:31 PM, Keith McGuigan wrote:
>
> I think it's ok as it is, if you need to check it in quick, but I agree
> that this probably should be rewritten better to make the logic more
> obvious.  Maybe separate clauses for reflection/lambda code?
>
>     ((!is_MAI && !is_MLI) ||
>     (is_MAI && VerifyReflectionBytecodes) ||
>     (is_MLI && VerifyLambdaBytecodes))
>
> Isn't this equivalent to:
>   (!is_MAI || VerifyReflectionBytecodes) &&
>   (!is_MLI || VerifyLambdaBytecodes)
>
>
>
> On Wed, Aug 28, 2013 at 8:50 PM, Karen Kinnear <Karen.Kinnear at oracle.com>wrote:
>
>> Thank you David. I agree, I was tempted to rewrite the entire method - in
>> particular, in a debugger
>> (so I didn't check the optimized code) we walk the entire && before we
>> make the initial call - in this
>> case the initial call would weed out more things faster potentially, so
>> ... But I chose not to rewrite since
>> they need this quickly and the shaking out would take quite a bit longer.
>>
>> thanks for the review,
>> Karen
>>
>> On Aug 28, 2013, at 8:48 PM, David Holmes wrote:
>>
>> > Hi Karen,
>> >
>> > I found the boolean logic very hard to follow there - not sure if the
>> refactoring helped or hindered :)
>> >
>> > But it looks okay.
>> >
>> > David
>> >
>> > On 29/08/2013 5:42 AM, Karen Kinnear wrote:
>> >> Please review - lambda team needs this change to get in by tomorrow so
>> >> they can push
>> >> the (8010433) metafactory change which is waiting on the vm. Thanks.
>> >>
>> >>
>> >> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
>> >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>> >>
>> >> Testing:
>> >> The failure comes if you apply an early patch of 8010433 to the jdk and
>> >> do not
>> >> make the vm change. So testing included 4 binaries: master, newjdk,
>> >> newvm, newjdkvm
>> >>
>> >> jtreg for SpinedBufferTest with various flags - these are the expected
>> >> results below
>> >> The key point is newjdk -Xverify: all fails
>> >> newjdkvm -Xverify:all passes, but if you also turn on
>> >> -XX:+VerifyLambdaBytecodes you see
>> >>    the verification error
>> >>
>> >> 1. master
>> >>  no flags: timed out
>> >>  -Xverify:all: timed out
>> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> >>
>> >> 2. newjdk
>> >>  no flags: timed out
>> >>  -Xverify:all
>> >>    java.lang.BootstrapMethodError: call site initialization exception
>> >> ... cause:
>> >>      VerifyError: Bad invokespecial instruction: current class isn't
>> >> assignable to reference class
>> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> >>
>> >> 3. newvm
>> >>   no flags: timed out
>> >>   rerun.sh: -Xverify:all: passed
>> >>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> >>   -XX:+VerifyLambdaBytecodes: passed, didn't try verification
>> >>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
>> >>
>> >> 4. newjdkvm
>> >>  rerun.sh: no flags: passed
>> >>  rerun.verify.sh: -Xverify:all: passed
>> >>  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
>> >>    Verification for java.util.streamIntPipeline$7$1$$Lambda$9 failed
>> >>
>> >> regression testing:
>> >> newvm:
>> >>   vm.quick.testlist - in progress
>> >>   jtreg java/util/stream - in progress
>> >>   jprt -stree . - in progress
>> >>
>> >> newvmjdk (Brian testing in lambda repo) - in progress
>> >>
>> >> thanks,
>> >> Karen
>> >>
>>
>>
>
>
> --
> - Keith McGuigan <keith.mcguigan at alumni.unh.edu>
>
>
>


-- 
- Keith McGuigan <keith.mcguigan at alumni.unh.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/ab2a71fc/attachment-0001.html 

From kamggg at gmail.com  Thu Aug 29 11:31:12 2013
From: kamggg at gmail.com (Keith McGuigan)
Date: Thu, 29 Aug 2013 14:31:12 -0400
Subject: S RFR: Lambda: verification error in generated lambda classes
In-Reply-To: <8BA6AF53-D39D-4821-8D63-E936FA4592B2@oracle.com>
References: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
	<521E9A45.8040809@oracle.com>
	<491B7272-B309-4193-BF8B-E7889441B6FB@oracle.com>
	<CAFUO74kYcSx5umWA_VY4Aq_R8UnHHcn3VaMsJ-N6qsuNKc4AtQ@mail.gmail.com>
	<8BA6AF53-D39D-4821-8D63-E936FA4592B2@oracle.com>
Message-ID: <CAFUO74kJ-0Qrztpou99dSUpcym-7S2x6=VjV=ONZxUSMuH5jZQ@mail.gmail.com>

I think there's an extra set of parenthesis that isn't needed, but other
than that, thanks, looks good!


On Thu, Aug 29, 2013 at 1:29 PM, Karen Kinnear <Karen.Kinnear at oracle.com>wrote:

> Keith, David,
>
> Many thanks for the suggestions. I think Keith's proposal is much simpler
> to read. I did
> a name change as well to hopefully make this more obvious.
>
> webrev.02:
>
> >> webrev: http://cr.openjdk.java.net/~acorn/8023872.02/webrev/
>> >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>>
>
> I redid the manual testing, and the longer tests are in progress again.
>
> thanks,
> Karen
>
> On Aug 28, 2013, at 10:31 PM, Keith McGuigan wrote:
>
> I think it's ok as it is, if you need to check it in quick, but I agree
> that this probably should be rewritten better to make the logic more
> obvious.  Maybe separate clauses for reflection/lambda code?
>
>     ((!is_MAI && !is_MLI) ||
>     (is_MAI && VerifyReflectionBytecodes) ||
>     (is_MLI && VerifyLambdaBytecodes))
>
> Isn't this equivalent to:
>   (!is_MAI || VerifyReflectionBytecodes) &&
>   (!is_MLI || VerifyLambdaBytecodes)
>
>
>
> On Wed, Aug 28, 2013 at 8:50 PM, Karen Kinnear <Karen.Kinnear at oracle.com>wrote:
>
>> Thank you David. I agree, I was tempted to rewrite the entire method - in
>> particular, in a debugger
>> (so I didn't check the optimized code) we walk the entire && before we
>> make the initial call - in this
>> case the initial call would weed out more things faster potentially, so
>> ... But I chose not to rewrite since
>> they need this quickly and the shaking out would take quite a bit longer.
>>
>> thanks for the review,
>> Karen
>>
>> On Aug 28, 2013, at 8:48 PM, David Holmes wrote:
>>
>> > Hi Karen,
>> >
>> > I found the boolean logic very hard to follow there - not sure if the
>> refactoring helped or hindered :)
>> >
>> > But it looks okay.
>> >
>> > David
>> >
>> > On 29/08/2013 5:42 AM, Karen Kinnear wrote:
>> >> Please review - lambda team needs this change to get in by tomorrow so
>> >> they can push
>> >> the (8010433) metafactory change which is waiting on the vm. Thanks.
>> >>
>> >>
>> >> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
>> >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>> >>
>> >> Testing:
>> >> The failure comes if you apply an early patch of 8010433 to the jdk and
>> >> do not
>> >> make the vm change. So testing included 4 binaries: master, newjdk,
>> >> newvm, newjdkvm
>> >>
>> >> jtreg for SpinedBufferTest with various flags - these are the expected
>> >> results below
>> >> The key point is newjdk -Xverify: all fails
>> >> newjdkvm -Xverify:all passes, but if you also turn on
>> >> -XX:+VerifyLambdaBytecodes you see
>> >>    the verification error
>> >>
>> >> 1. master
>> >>  no flags: timed out
>> >>  -Xverify:all: timed out
>> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> >>
>> >> 2. newjdk
>> >>  no flags: timed out
>> >>  -Xverify:all
>> >>    java.lang.BootstrapMethodError: call site initialization exception
>> >> ... cause:
>> >>      VerifyError: Bad invokespecial instruction: current class isn't
>> >> assignable to reference class
>> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> >>
>> >> 3. newvm
>> >>   no flags: timed out
>> >>   rerun.sh: -Xverify:all: passed
>> >>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> >>   -XX:+VerifyLambdaBytecodes: passed, didn't try verification
>> >>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
>> >>
>> >> 4. newjdkvm
>> >>  rerun.sh: no flags: passed
>> >>  rerun.verify.sh: -Xverify:all: passed
>> >>  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
>> >>    Verification for java.util.streamIntPipeline$7$1$$Lambda$9 failed
>> >>
>> >> regression testing:
>> >> newvm:
>> >>   vm.quick.testlist - in progress
>> >>   jtreg java/util/stream - in progress
>> >>   jprt -stree . - in progress
>> >>
>> >> newvmjdk (Brian testing in lambda repo) - in progress
>> >>
>> >> thanks,
>> >> Karen
>> >>
>>
>>
>
>
> --
> - Keith McGuigan <keith.mcguigan at alumni.unh.edu>
>
>
>


-- 
- Keith McGuigan <keith.mcguigan at alumni.unh.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/4458d3d9/attachment.html 

From lois.foltan at oracle.com  Thu Aug 29 11:33:29 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 29 Aug 2013 14:33:29 -0400
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521BA02E.6080901@oracle.com>
References: <521BA02E.6080901@oracle.com>
Message-ID: <521F93F9.4040007@oracle.com>


Please review the following updated webrev:

Internal webrev:

    http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/

Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
          runtime/6878713/Test6878713.sh fails on mac

     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
https://bugs.openjdk.java.net/browse/JDK-8022140

Summary of fix:
     On MacOS, currently Hotspot is built specifying the -fcheck-new 
command line option to the llvm-g++ compiler.
     The -fcheck-new option directs the compiler to "check that the 
pointer returned by |operator new| is non-null
      before attempting to modify the storage allocated."  The clang++ 
compiler does not support the
      -fcheck-new option.  To obtain similiar functionality when 
building Hotspot with clang++, empty exception
      throw() specifications must be added to all user-defined operator 
new()'s.

Tests:
      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, MacOS 
(llvm-g++ & clang++)
      Ran vm.quick.testlist on MacOS clang++ built Hotspot image

Original Testing:
      Solaris: built fastdebug & product images
      Linux: built fastdebug & product images
      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
                     built fastdebug & product images using clang++ - 
ran JTREG, JCK vm & lang, vm.quick.testlist
      Windows:  built fastdebug & product images with VS2010

Thank you,
Lois

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/49eaa416/attachment.html 

From lois.foltan at oracle.com  Thu Aug 29 11:37:55 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 29 Aug 2013 14:37:55 -0400
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521D6F68.6050000@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>
	<521CDE52.2030407@oracle.com> <521D6F68.6050000@oracle.com>
Message-ID: <521F9503.3010108@oracle.com>

Hi Yumin,

I do have some follow on review comments:

arguments.cpp - looks good, no comments

ostream.hpp - looks good, no comments

ostream.cpp -

     - Have you tried a file name that is 255 characters?  It would seem 
that after you appended the pid + timestamp + .current + # you could 
overrun this buffer?

    439 #define FILENAMEBUFLEN 256
         and subsequent use at
    466 char tempbuf[FILENAMEBUFLEN];
         467 jio_snprintf(tempbuf, sizeof(tempbuf), "%s.%d" CURRENTAPPX,
    _file_name, _cur_file_num);

     - I would also like to point out in line #467, there may not be a 
need for "sizeof(tempbuf)", isn't it just FILENAMEBUFLEN?
       Please check the use of "sizeof()" in the jio_sprintf statements, 
I think all are known.

    - Related to my first comment.  If you have a time_msg that is 
FILENAMEBUFLEN and you try to concatenate it with a file_name that is 
FILENAMEBUFLEN + the
      os::local_time_string, you've overrun your buffer.

    493 char time_msg[FILENAMEBUFLEN];
          494 char time_str[EXTRACHARLEN];
          495 char current_file_name[FILENAMEBUFLEN];
    496 char renamed_file_name[FILENAMEBUFLEN];
          ...
          530 jio_snprintf(time_msg, sizeof(time_msg), "%s GC log file
    has reached the"
          531                                         " maximum size.
    Saved as %s\n",
          532 os::local_time_string((char *)time_str, sizeof(time_str)),
          533 renamed_file_name);

     - Line #538 dealing with the rename of <file_name>.current.#.  I 
don't prefer the use of .current. Take for example a user
       specified on the command line -XX:NumberOfGCLogFiles=5, but there 
is enough -Xloggc info generated to fit in 7 files.  This
       situation will cause the log file rotation to rotate back on 
itself.  So, file #0 will be reopened and used as the 6th file, and
       then the rotation will progress and finish dumping Xloggc 
information into the last file which would be <file_name>.current.1,
       correct?  So a user would be left with the following files.

                         file_name.0 (which now has a later timestamp in 
its name than file # 1 thru 4)
                         file_name.1
                         file_name.2
                         file_name.3
                         file_name.4
                         file_name.current.1

       I find this confusing, would you consider having the -Xloggc 
information be dumped into the current #'ed file directly?

     - Line 587 FLAG_SET_DEFAULT(UseGCLogFileRotation, false);
       I like that you implemented the idea to turn off GC log file 
rotation and continue with the current file if you can't open the next 
file, thank you.

Thank you,
Lois

On 8/27/2013 11:32 PM, Yumin Qi wrote:
> Hi,
>
>  Based on the discussion, I updated the webrev, and in this version
> 1) deleted unused rotatingFileStream  constructor, which keep code 
> shorter.
> 2) removed reformat_filename in previous version.
> 3) still keep original design, that if no rotation, just use file name 
> given by -Xloggc:<filename>.
>
> Others are basically same.
>
> Please take a look and comment.
>
> http://cr.openjdk.java.net/~minqi/7164841/webrev02 
> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev02>
>
> Thanks
> Yumin
>
> On 8/27/2013 10:13 AM, Tao Mao wrote:
>>
>>
>> On 8/27/13 1:01 AM, Bengt Rutisson wrote:
>>>
>>> Yumin,
>>>
>>> On 8/26/13 7:01 PM, Yumin Qi wrote:
>>>> Bengt,
>>>>
>>>>   Thanks for your comments.
>>>>   Yes, as you said, the purpose of rotating logs is primarily 
>>>> targeted for saving disk space. This bug is supplying customers 
>>>> another option to prevent the previous gc logs from removed by 
>>>> restart app without making copy. Now with this pid and time stamp 
>>>> included in file name,  we have more options for users. It is up to 
>>>> user to make decision to or not to keep the logs. We cannot handle 
>>>> all the requests in JVM, but we can offer the choices for users I 
>>>> think. Any way, with either the previous rotating version, or the 
>>>> one I am working, the logs will not grow constantly without limit 
>>>> to blow storage out as long as users give enough attention.
>>>>
>>>>   My concern is for no log rotation, should we still use time stamp 
>>>> in file name? I have one version for this, I hope get more comments 
>>>> for that.
>>>
>>> Sorry if I wasn't clear before. I am not worried about the case when 
>>> log rotation is turned on. What I was worried about was the case 
>>> where a user is not using log rotation but is still piping the GC 
>>> output to a file. That file will be overwritten every time the VM is 
>>> restarted. If we add time stamps to the file name for this case then 
>>> the file will not be overwritten. I think that is a bit of a scary 
>>> change. That's all.
>>
>> If you are worried about the case where a user is not using log 
>> rotation but creating a new file for each restart, you should be 
>> almost equivalently worried about the case where a user is using log 
>> rotation and having many rotated logs created which are different for 
>> each VM restart. Basically, we are creating even more files over 
>> time, which falls into your concern.
>>
>> At this point, I'm fine with either choice for they have pros and 
>> cons. If we always append date and time to log file names, customers 
>> may say "the logs are 'eating' my disk"; if you don't do that, the 
>> customers would still complain the log is overwritten after a restart 
>> (I saw these kinds of CR's twice).
>>
>> Thanks.
>> Tao
>>
>>>
>>> Bengt
>>>
>>>>
>>>>   More comments are appreciated by sending to more wide audience, 
>>>> especially sustaining, they have more experience with customer 
>>>> request.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>>
>>>> On 8/26/2013 4:47 AM, Bengt Rutisson wrote:
>>>>>
>>>>> Hi Yumin and Tao,
>>>>>
>>>>> I have not reviewed the code change but I have a comment inlined 
>>>>> below.
>>>>>
>>>>> On 8/24/13 1:05 AM, Yumin Qi wrote:
>>>>>> Tao,
>>>>>>
>>>>>>   Thanks for your review.
>>>>>>
>>>>>> On 8/23/2013 3:33 PM, Tao Mao wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I reviewed most of the code and test-ran a build from it. It's a 
>>>>>>> very cool and important improvement.
>>>>>>>
>>>>>>> Thank you for putting together these on our wishlist for long.
>>>>>>>
>>>>>>> Below are some comments.
>>>>>>>
>>>>>>> 1. src/share/vm/runtime/arguments.cpp
>>>>>>>
>>>>>>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>>>>>>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>>>>>>
>>>>>>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>>>>>>
>>>>>>> I worked on a problem of enabling gc log limit over 2G 
>>>>>>> (JDK-7122222). So it seems that customers sometimes want gc logs 
>>>>>>> to be very large.
>>>>>>>
>>>>>> Sure, will add.
>>>>>>> 2. src/share/vm/runtime/arguments.hpp
>>>>>>>
>>>>>>> (1) with the current changeset, we only append date&time to 
>>>>>>> file_name w/ +UseGCLogFileRotation; if not, we won't have 
>>>>>>> date&time info.
>>>>>>>
>>>>>>> I think it would be useful to let both cases (w/ and w/o 
>>>>>>> UseGCLogFileRotation) have date&time in order to solve the 
>>>>>>> overwritten problem (e.g. JDK-8020667). In fact, having that, we 
>>>>>>> actually solve JDK-8020667.
>>>>>>>
>>>>>>> If you want to have that, basically you need to work on the 
>>>>>>> FileStream constructor methods fileStream().
>>>>>>>
>>>>>> I can change that, if no objection from others. This also will 
>>>>>> simplify the setting of file name here.
>>>>>
>>>>> I think appending a timestamp to the log file name is a nice idea, 
>>>>> but I think it is also a bit scary. There are users who restart 
>>>>> their applications regularly. With the suggested idea such users 
>>>>> will now risk filling up their disk space with log files. I 
>>>>> imagine that that will not be appreciated by everyone. Such a 
>>>>> change should probably be discussed more thoroughly than just in a 
>>>>> review request.
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>>
>>>>>
>>>>>>
>>>>>>> (2) Would it be better to rename method name reformat_filename() 
>>>>>>> to extend_filename()?
>>>>>>>
>>>>>>> (3) Typos and suggestion
>>>>>>> 537 // rotate file in names filename.0, filename.1, ..., 
>>>>>>> filename.<NumberOfGCLogFiles - 1>
>>>>>>> *=> extended_filename.0*
>>>>>>>
>>>>>>> 538 // filename contains pid and time when the fist file 
>>>>>>> created. The current filename is
>>>>>>> *=> *the*first *file created.
>>>>>>>
>>>>>>> 539 // gc_log_file_name + pid<pid> + 
>>>>>>> YYYY-MM-DD_HH-MM-SS.<i>.current, where i is current
>>>>>>> 540 // rotation file number. After it reaches max file size, the 
>>>>>>> file will be saved and
>>>>>>> 541 // renamed with .current removed from its tail.
>>>>>>>
>>>>>> Will change that.
>>>>>>> 3. For your point 5), I don't quite get it. In my test-run, I 
>>>>>>> tried to change file permission to unreadable and unwritable, 
>>>>>>> but VM would later change the permission back anyway.
>>>>>>>
>>>>>>> So could you bring up some use cases of that functionality to 
>>>>>>> give more details?
>>>>>>>
>>>>>> Changing file permission will not stop the file create, in this 
>>>>>> rotation, the file opened/saved/removed/renamed -> then repeat. 
>>>>>> What I have done is change the while directory to read only, then 
>>>>>> the create failed so rotation stopped.
>>>>>>
>>>>>>> 4. Will you write jtreg tests for this functionality? It looks 
>>>>>>> possible to write some tests, at least checking the format of 
>>>>>>> log names.
>>>>>>>
>>>>>> Good suggestion, I will add one.
>>>>>>
>>>>>>> Thanks.
>>>>>>> Tao
>>>>>>>
>>>>>>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>>>>>>> Could I get  a GC staff review the change? Need more reviewers 
>>>>>>>> to push this in.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>
>>>>>>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>>>>>>> Hi, all
>>>>>>>>>
>>>>>>>>>   This is second version after feedback from first round.
>>>>>>>>>   The changes are:
>>>>>>>>>
>>>>>>>>>   1) file name will be based on gc log file name 
>>>>>>>>> (-Xloggc:filename), pid (process id) and time when the first 
>>>>>>>>> rotation file created:
>>>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>>>>>>   2) If rotate in same file, file name is as in 1), if rotate 
>>>>>>>>> in multiple files, .<i> will append to above file name.
>>>>>>>>>   3) every time file rotated, file name and time when file 
>>>>>>>>> created will be logged to head/tail, this is same as first 
>>>>>>>>> version.
>>>>>>>>>   4) current file has name 
>>>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>>>>>>        This is similar to first version.
>>>>>>>>>        By adapting such name format we will never loss logs in 
>>>>>>>>> case apps stops and restart, the log files will not be 
>>>>>>>>> overwritten since time stamp in file names.
>>>>>>>>>    5) If open file failed, turn off gc log rotation.
>>>>>>>>>         If due to some reason, file operation failed (such as 
>>>>>>>>> permission changed etc), with log file opened, logging still 
>>>>>>>>> works, but at
>>>>>>>>>         saving and renaming, the file operation will fail, 
>>>>>>>>> this will lead not all files saved.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>>>>>>
>>>>>>>>>      Tested with jtreg, JPRT.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>   Can I have your review for this small changes?
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>>>>>>
>>>>>>>>>>    This is for a enhancement to add head/tail message to the 
>>>>>>>>>> logging files to assist reading GC output.
>>>>>>>>>>    1. modified prompt message if invalid arguments used for 
>>>>>>>>>> log rotating;
>>>>>>>>>>    2. add time and file name message to log file head/tail.
>>>>>>>>>>    3. for easily identify which log file is current, use file 
>>>>>>>>>> name like <filename>.n.current, after it reaches maximum 
>>>>>>>>>> size, rename it to <filename>.n
>>>>>>>>>>         On Windows, there is no F_OK (existing test) 
>>>>>>>>>> definition, F_OK is defined as "0" and for _access of VC++, 
>>>>>>>>>> it just describes:
>>>>>>>>>>
>>>>>>>>>> modevalue
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Checks file for
>>>>>>>>>>
>>>>>>>>>> 00
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Existence only
>>>>>>>>>>
>>>>>>>>>> 02
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Write-only
>>>>>>>>>>
>>>>>>>>>> 04
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Read-only
>>>>>>>>>>
>>>>>>>>>> 06
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Read and write
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>>>>>>> The definition are consistent with unistd.h.
>>>>>>>>>>
>>>>>>>>>>     Test: JPRT and jtreg.
>>>>>>>>>>
>>>>>>>>>>    Thanks
>>>>>>>>>>    Yumin
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/975e996f/attachment-0001.html 

From harold.seigel at oracle.com  Thu Aug 29 11:44:04 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 29 Aug 2013 14:44:04 -0400
Subject: RFR S 8023381: VM fails to initialize in
	runtime/CDSCompressedKPtrs/XShareAuto.java
	runtime/SharedArchiveFile/CdsSameObjectAlignment.java
Message-ID: <521F9674.8050703@oracle.com>

Hi,

Please review this small change to fix a problem with some of the JTreg 
CDS tests.  The fix changes the tests to look for a more generic reason 
for why the JVM could not use CDS, causing it to exit.  The tests now 
look for "Unable to use shared archive".  This message is always printed 
when the JVM exits because it could not use CDS.

Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8023381/ 
<http://cr.openjdk.java.net/%7Ehseigel/bug_8023381/>

Bug: https://bugs.openjdk.java.net/browse/JDK-8023381

The fixed tests were run on Linux 32 and 64 bit, Solaris Sparc 10 and 
11, Solaris x86 10, Mac OS X, and Windows.

Thanks! Harold


From coleen.phillimore at oracle.com  Thu Aug 29 11:50:22 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 29 Aug 2013 14:50:22 -0400
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F93F9.4040007@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
Message-ID: <521F97EE.9060407@oracle.com>


Lois,

This does looks better than the NOEXCEPT macros.  Can other people 
review this today?  We need this for the clang c++ compiler upgrade testing.

Thanks,
Coleen

On 08/29/2013 02:33 PM, Lois Foltan wrote:
>
> Please review the following updated webrev:
>
> Internal webrev:
>
> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>
> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>          runtime/6878713/Test6878713.sh fails on mac
>
>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
> https://bugs.openjdk.java.net/browse/JDK-8022140
>
> Summary of fix:
>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
> command line option to the llvm-g++ compiler.
>     The -fcheck-new option directs the compiler to "check that the 
> pointer returned by |operator new| is non-null
>      before attempting to modify the storage allocated."  The clang++ 
> compiler does not support the
>      -fcheck-new option.  To obtain similiar functionality when 
> building Hotspot with clang++, empty exception
>      throw() specifications must be added to all user-defined operator 
> new()'s.
>
> Tests:
>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, MacOS 
> (llvm-g++ & clang++)
>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>
> Original Testing:
>      Solaris: built fastdebug & product images
>      Linux: built fastdebug & product images
>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>                     built fastdebug & product images using clang++ - 
> ran JTREG, JCK vm & lang, vm.quick.testlist
>      Windows:  built fastdebug & product images with VS2010
>
> Thank you,
> Lois
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/114884ab/attachment.html 

From john.coomes at oracle.com  Thu Aug 29 12:00:04 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 19:00:04 +0000
Subject: hg: hsx/hotspot-emb: 6 new changesets
Message-ID: <20130829190005.161B3623D4@hg.openjdk.java.net>

Changeset: 00dcfaa6bc01
Author:    aefimov
Date:      2013-08-16 18:40 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/00dcfaa6bc01

8021820: Number of opened files used in select() is limited to 1024 [macosx]
Reviewed-by: alanb, chegar, tbell, smarks

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: e8a3edda1f60
Author:    lana
Date:      2013-08-20 17:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/e8a3edda1f60

Merge


Changeset: 056398db9dcb
Author:    lana
Date:      2013-08-23 14:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/056398db9dcb

Merge

! common/autoconf/generated-configure.sh

Changeset: f8405a0fa69c
Author:    erikj
Date:      2013-08-26 13:43 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/f8405a0fa69c

8023216: Feedback on README-builds.html
Reviewed-by: anthony, robilad, tbell

! README-builds.html

Changeset: 5166118c5917
Author:    katleman
Date:      2013-08-26 17:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/5166118c5917

Merge


Changeset: 246cdbaa6c62
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/rev/246cdbaa6c62

Added tag jdk8-b105 for changeset 5166118c5917

! .hgtags


From john.coomes at oracle.com  Thu Aug 29 12:00:12 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 19:00:12 +0000
Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b105 for changeset
	4e38de7c767e
Message-ID: <20130829190016.2E95D623D5@hg.openjdk.java.net>

Changeset: 2e3a056c84a7
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/2e3a056c84a7

Added tag jdk8-b105 for changeset 4e38de7c767e

! .hgtags


From john.coomes at oracle.com  Thu Aug 29 12:00:28 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 19:00:28 +0000
Subject: hg: hsx/hotspot-emb/jaxp: 5 new changesets
Message-ID: <20130829190046.5FA7C623D6@hg.openjdk.java.net>

Changeset: 4e23bc205d9d
Author:    joehw
Date:      2013-08-09 12:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/4e23bc205d9d

8022548: SPECJVM2008 has errors introduced in 7u40-b34
Reviewed-by: chegar, lancea

! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java
! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java
! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java

Changeset: 9800647936dd
Author:    lana
Date:      2013-08-13 18:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/9800647936dd

Merge


Changeset: d4d6422ec564
Author:    lana
Date:      2013-08-20 17:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/d4d6422ec564

Merge


Changeset: 09a46ec11f88
Author:    lana
Date:      2013-08-23 14:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/09a46ec11f88

Merge


Changeset: d3be8e3b429d
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/d3be8e3b429d

Added tag jdk8-b105 for changeset 09a46ec11f88

! .hgtags


From john.coomes at oracle.com  Thu Aug 29 12:01:17 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 19:01:17 +0000
Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b105 for changeset
	88390df7ed2c
Message-ID: <20130829190127.6C1F0623D7@hg.openjdk.java.net>

Changeset: 01be6f93d0a4
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/01be6f93d0a4

Added tag jdk8-b105 for changeset 88390df7ed2c

! .hgtags


From harold.seigel at oracle.com  Thu Aug 29 12:02:29 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 29 Aug 2013 15:02:29 -0400
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F97EE.9060407@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521F97EE.9060407@oracle.com>
Message-ID: <521F9AC5.8050504@oracle.com>

Hi Lois,

The changes look good.

Thanks, Harold

On 8/29/2013 2:50 PM, Coleen Phillimore wrote:
>
> Lois,
>
> This does looks better than the NOEXCEPT macros.  Can other people 
> review this today?  We need this for the clang c++ compiler upgrade 
> testing.
>
> Thanks,
> Coleen
>
> On 08/29/2013 02:33 PM, Lois Foltan wrote:
>>
>> Please review the following updated webrev:
>>
>> Internal webrev:
>>
>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>>
>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>          runtime/6878713/Test6878713.sh fails on mac
>>
>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>
>> Summary of fix:
>>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
>> command line option to the llvm-g++ compiler.
>>     The -fcheck-new option directs the compiler to "check that the 
>> pointer returned by |operator new| is non-null
>>      before attempting to modify the storage allocated."  The clang++ 
>> compiler does not support the
>>      -fcheck-new option.  To obtain similiar functionality when 
>> building Hotspot with clang++, empty exception
>>      throw() specifications must be added to all user-defined 
>> operator new()'s.
>>
>> Tests:
>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, 
>> MacOS (llvm-g++ & clang++)
>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>
>> Original Testing:
>>      Solaris: built fastdebug & product images
>>      Linux: built fastdebug & product images
>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>                     built fastdebug & product images using clang++ - 
>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>      Windows:  built fastdebug & product images with VS2010
>>
>> Thank you,
>> Lois
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/fb167163/attachment.html 

From vladimir.kozlov at oracle.com  Thu Aug 29 12:08:31 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 29 Aug 2013 12:08:31 -0700
Subject: RFR S 8023381: VM fails to initialize in
	runtime/CDSCompressedKPtrs/XShareAuto.java
	runtime/SharedArchiveFile/CdsSameObjectAlignment.java
In-Reply-To: <521F9674.8050703@oracle.com>
References: <521F9674.8050703@oracle.com>
Message-ID: <521F9C2F.30504@oracle.com>

Looks fine.

Vladimir

On 8/29/13 11:44 AM, harold seigel wrote:
> Hi,
>
> Please review this small change to fix a problem with some of the JTreg
> CDS tests.  The fix changes the tests to look for a more generic reason
> for why the JVM could not use CDS, causing it to exit.  The tests now
> look for "Unable to use shared archive".  This message is always printed
> when the JVM exits because it could not use CDS.
>
> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8023381/
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8023381/>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8023381
>
> The fixed tests were run on Linux 32 and 64 bit, Solaris Sparc 10 and
> 11, Solaris x86 10, Mac OS X, and Windows.
>
> Thanks! Harold
>

From calvin.cheung at oracle.com  Thu Aug 29 12:20:02 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 29 Aug 2013 12:20:02 -0700
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F97EE.9060407@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521F97EE.9060407@oracle.com>
Message-ID: <521F9EE2.2000403@oracle.com>

Hi Lois,

src/share/vm/code/nmethod.cpp

803 void* nmethod::operator new(size_t size, int nmethod_size) throw() {

The above line looks the same to me after the change.
So perhaps the file doesn't need to be changed (other than the copyright 
year)?

Calvin

On 8/29/2013 11:50 AM, Coleen Phillimore wrote:
>
> Lois,
>
> This does looks better than the NOEXCEPT macros.  Can other people 
> review this today?  We need this for the clang c++ compiler upgrade 
> testing.
>
> Thanks,
> Coleen
>
> On 08/29/2013 02:33 PM, Lois Foltan wrote:
>>
>> Please review the following updated webrev:
>>
>> Internal webrev:
>>
>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>>
>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>          runtime/6878713/Test6878713.sh fails on mac
>>
>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>
>> Summary of fix:
>>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
>> command line option to the llvm-g++ compiler.
>>     The -fcheck-new option directs the compiler to "check that the 
>> pointer returned by |operator new| is non-null
>>      before attempting to modify the storage allocated."  The clang++ 
>> compiler does not support the
>>      -fcheck-new option.  To obtain similiar functionality when 
>> building Hotspot with clang++, empty exception
>>      throw() specifications must be added to all user-defined 
>> operator new()'s.
>>
>> Tests:
>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, 
>> MacOS (llvm-g++ & clang++)
>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>
>> Original Testing:
>>      Solaris: built fastdebug & product images
>>      Linux: built fastdebug & product images
>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>                     built fastdebug & product images using clang++ - 
>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>      Windows:  built fastdebug & product images with VS2010
>>
>> Thank you,
>> Lois
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/fbfa08f4/attachment-0001.html 

From harold.seigel at oracle.com  Thu Aug 29 12:23:06 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 29 Aug 2013 15:23:06 -0400
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F9EE2.2000403@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521F97EE.9060407@oracle.com> <521F9EE2.2000403@oracle.com>
Message-ID: <521F9F9A.9050502@oracle.com>

Hi Calvin,

It is not easy to see, but a space was removed from between 'throw' and 
'()'.

Harold

On 8/29/2013 3:20 PM, Calvin Cheung wrote:
> Hi Lois,
>
> src/share/vm/code/nmethod.cpp
>
> 803 void* nmethod::operator new(size_t size, int nmethod_size) throw() {
>
> The above line looks the same to me after the change.
> So perhaps the file doesn't need to be changed (other than the 
> copyright year)?
>
> Calvin
>
> On 8/29/2013 11:50 AM, Coleen Phillimore wrote:
>>
>> Lois,
>>
>> This does looks better than the NOEXCEPT macros.  Can other people 
>> review this today?  We need this for the clang c++ compiler upgrade 
>> testing.
>>
>> Thanks,
>> Coleen
>>
>> On 08/29/2013 02:33 PM, Lois Foltan wrote:
>>>
>>> Please review the following updated webrev:
>>>
>>> Internal webrev:
>>>
>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>>>
>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>>          runtime/6878713/Test6878713.sh fails on mac
>>>
>>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>
>>> Summary of fix:
>>>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
>>> command line option to the llvm-g++ compiler.
>>>     The -fcheck-new option directs the compiler to "check that the 
>>> pointer returned by |operator new| is non-null
>>>      before attempting to modify the storage allocated." The clang++ 
>>> compiler does not support the
>>>      -fcheck-new option.  To obtain similiar functionality when 
>>> building Hotspot with clang++, empty exception
>>>      throw() specifications must be added to all user-defined 
>>> operator new()'s.
>>>
>>> Tests:
>>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, 
>>> MacOS (llvm-g++ & clang++)
>>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>>
>>> Original Testing:
>>>      Solaris: built fastdebug & product images
>>>      Linux: built fastdebug & product images
>>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>>                     built fastdebug & product images using clang++ - 
>>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>>      Windows:  built fastdebug & product images with VS2010
>>>
>>> Thank you,
>>> Lois
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/fe63583e/attachment.html 

From mikhailo.seledtsov at oracle.com  Thu Aug 29 12:31:17 2013
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Thu, 29 Aug 2013 15:31:17 -0400
Subject: RFR S 8023381: VM fails to initialize in
	runtime/CDSCompressedKPtrs/XShareAuto.java
	runtime/SharedArchiveFile/CdsSameObjectAlignment.java
In-Reply-To: <521F9C2F.30504@oracle.com>
References: <521F9674.8050703@oracle.com> <521F9C2F.30504@oracle.com>
Message-ID: <521FA185.2020304@oracle.com>

Looks good.

Misha
On 8/29/2013 3:08 PM, Vladimir Kozlov wrote:
> Looks fine.
>
> Vladimir
>
> On 8/29/13 11:44 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this small change to fix a problem with some of the JTreg
>> CDS tests.  The fix changes the tests to look for a more generic reason
>> for why the JVM could not use CDS, causing it to exit.  The tests now
>> look for "Unable to use shared archive".  This message is always printed
>> when the JVM exits because it could not use CDS.
>>
>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8023381/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8023381/>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023381
>>
>> The fixed tests were run on Linux 32 and 64 bit, Solaris Sparc 10 and
>> 11, Solaris x86 10, Mac OS X, and Windows.
>>
>> Thanks! Harold
>>


From daniel.daugherty at oracle.com  Thu Aug 29 12:33:09 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 29 Aug 2013 13:33:09 -0600
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F93F9.4040007@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
Message-ID: <521FA1F5.80301@oracle.com>

On 8/29/13 12:33 PM, Lois Foltan wrote:
>
> Please review the following updated webrev:
>
> Internal webrev:

Not an "internal" webrev. :-)


>
> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/

src/share/vm/adlc/arena.cpp
src/share/vm/adlc/arena.hpp
src/share/vm/adlc/main.cpp
src/share/vm/asm/codeBuffer.hpp
src/share/vm/c1/c1_Compilation.hpp
src/share/vm/c1/c1_Instruction.hpp
src/share/vm/code/codeBlob.cpp
src/share/vm/code/codeBlob.hpp
src/share/vm/code/debugInfoRec.cpp
src/share/vm/code/nmethod.cpp
src/share/vm/code/nmethod.hpp
src/share/vm/code/relocInfo.hpp
src/share/vm/code/vtableStubs.cpp
src/share/vm/code/vtableStubs.hpp
src/share/vm/gc_implementation/shared/gcUtil.hpp
src/share/vm/libadt/port.hpp
src/share/vm/memory/allocation.cpp
src/share/vm/memory/allocation.hpp
src/share/vm/memory/allocation.inline.hpp
src/share/vm/memory/memRegion.cpp
src/share/vm/memory/memRegion.hpp
src/share/vm/oops/klass.cpp
src/share/vm/oops/klass.hpp
src/share/vm/oops/symbol.cpp
src/share/vm/oops/symbol.hpp
src/share/vm/opto/callGenerator.hpp
src/share/vm/opto/callnode.hpp
src/share/vm/opto/machnode.hpp
src/share/vm/opto/node.hpp
src/share/vm/opto/type.hpp
src/share/vm/runtime/fprofiler.cpp
src/share/vm/runtime/handles.cpp
src/share/vm/runtime/handles.hpp
src/share/vm/runtime/interfaceSupport.hpp
src/share/vm/runtime/objectMonitor.hpp
src/share/vm/runtime/park.cpp
src/share/vm/runtime/park.hpp
src/share/vm/runtime/thread.hpp
src/share/vm/services/memRecorder.hpp
src/share/vm/services/memTrackWorker.cpp
src/share/vm/services/memTrackWorker.hpp
src/share/vm/utilities/array.hpp
     Yikes, this list is scary...

     But I reviewed it via the patch link instead...

     Changes are restricted to:

     - additions of "throw()" in operator new() definitions
       and operator new() declarations
     - white space changes to make things line up
     - copyright updates

     Thumbs up!

     I didn't try to verify that all the operator new() declarations
     and definitions were covered. I don't know if there is an auto-magic
     to perform such a verification.

     Please ping Vladimir Kozlov about this change so that PPC work
     that is being done can also update their operator new() stuff.

Dan



>
> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>          runtime/6878713/Test6878713.sh fails on mac
>
>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
> https://bugs.openjdk.java.net/browse/JDK-8022140
>
> Summary of fix:
>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
> command line option to the llvm-g++ compiler.
>     The -fcheck-new option directs the compiler to "check that the 
> pointer returned by |operator new| is non-null
>      before attempting to modify the storage allocated."  The clang++ 
> compiler does not support the
>      -fcheck-new option.  To obtain similiar functionality when 
> building Hotspot with clang++, empty exception
>      throw() specifications must be added to all user-defined operator 
> new()'s.
>
> Tests:
>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, MacOS 
> (llvm-g++ & clang++)
>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>
> Original Testing:
>      Solaris: built fastdebug & product images
>      Linux: built fastdebug & product images
>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>                     built fastdebug & product images using clang++ - 
> ran JTREG, JCK vm & lang, vm.quick.testlist
>      Windows:  built fastdebug & product images with VS2010
>
> Thank you,
> Lois
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/7c3dc3df/attachment.html 

From john.coomes at oracle.com  Thu Aug 29 12:04:48 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 19:04:48 +0000
Subject: hg: hsx/hotspot-emb/jdk: 98 new changesets
Message-ID: <20130829193304.1E6A2623DD@hg.openjdk.java.net>

Changeset: 2722f4000b65
Author:    jgodinez
Date:      2013-08-15 11:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2722f4000b65

8023045: [MacOSX] PrinterIOException when printing a JComponent
Reviewed-by: bae, jchen

! src/share/classes/sun/print/PSPrinterJob.java

Changeset: b44ce67c0565
Author:    vadim
Date:      2013-08-16 15:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b44ce67c0565

8013446: [parfait] Memory leak in jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
Reviewed-by: bae, prr

! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c

Changeset: dadd43e02a79
Author:    prr
Date:      2013-08-19 03:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/dadd43e02a79

8017580: Crash in font loading code on Linux (due to use of reflection)
Reviewed-by: bae, vadim

! src/share/native/sun/font/sunFont.c
! src/share/native/sun/font/sunfontids.h

Changeset: 0c950b2be7ab
Author:    jgodinez
Date:      2013-08-19 11:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0c950b2be7ab

8022241: [macosx] [PIT] lookupPrintServices() returns one too long array
Reviewed-by: prr, jchen

! src/solaris/classes/sun/print/UnixPrintServiceLookup.java

Changeset: 64be71ae6185
Author:    lana
Date:      2013-08-20 17:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/64be71ae6185

Merge


Changeset: 903a279f1fce
Author:    ant
Date:      2013-08-09 05:20 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/903a279f1fce

8013611: Modal dialog fails to obtain keyboard focus
Reviewed-by: leonidr

! src/share/classes/java/awt/KeyboardFocusManager.java
+ test/java/awt/Focus/8013611/JDK8013611.java

Changeset: 2cd1a041381b
Author:    alexsch
Date:      2013-08-09 14:16 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2cd1a041381b

7121409: Two conformance tests for AccessibleText.getCharacterBounds(int i) fail
Reviewed-by: serb

! src/share/classes/javax/swing/JLabel.java

Changeset: 4702ab74b70a
Author:    serb
Date:      2013-08-13 15:41 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4702ab74b70a

7027045: (doc) java/awt/Window.java has several typos in javadoc
Reviewed-by: art, serb
Contributed-by: konstantin.perikov at gmail.com

! src/share/classes/java/awt/Window.java

Changeset: 149bf2400fa1
Author:    lana
Date:      2013-08-13 15:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/149bf2400fa1

Merge

- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: c5db3ec83cba
Author:    pchelko
Date:      2013-08-14 16:17 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c5db3ec83cba

8013454: [parfait] Memory leak in jdk/src/windows/native/sun/windows/awt_Cursor.cpp
8012079: [parfait] possible null pointer dereference in jdk/src/windows/native/sun/windows/awt_Font.cpp
Reviewed-by: art, serb

! src/windows/native/sun/windows/awt_Cursor.cpp
! src/windows/native/sun/windows/awt_Font.cpp

Changeset: 1d6ce0070fd3
Author:    pchelko
Date:      2013-08-14 17:20 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1d6ce0070fd3

7173464: Clipboard.getAvailableDataFlavors: Comparison method violates contract
Reviewed-by: anthony, art, serb

! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
+ test/sun/awt/datatransfer/DataFlavorComparatorTest.java

Changeset: 3930a827160a
Author:    leonidr
Date:      2013-08-15 01:17 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3930a827160a

8022997: [macosx] Remaining duplicated key events
Reviewed-by: anthony, serb

! src/macosx/native/sun/awt/CMenuItem.m
! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java

Changeset: d7a34d7e7f22
Author:    alitvinov
Date:      2013-08-15 14:20 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d7a34d7e7f22

7191018: Manual test closed/java/awt/JAWT causes JVM to crash starting from JDK 5
Reviewed-by: anthony, serb

! src/solaris/native/sun/awt/awt_DrawingSurface.c

Changeset: c089e93e6444
Author:    serb
Date:      2013-08-16 16:52 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c089e93e6444

8020051: [TEST_BUG] Testcase for 8004859 has a typo
Reviewed-by: anthony

! test/java/awt/Graphics2D/Test8004859/Test8004859.java

Changeset: e3316cd6ca47
Author:    serb
Date:      2013-08-16 20:56 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e3316cd6ca47

8006085: [findbugs] a warning on javax.sound.sampled.DataLine$Info constructor
Reviewed-by: art, prr

! src/share/classes/javax/sound/sampled/DataLine.java

Changeset: 64dc24e0d577
Author:    serb
Date:      2013-08-16 21:18 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/64dc24e0d577

8005980: [findbugs] More com.sun.media.sound.* warnings
Reviewed-by: art, prr

! src/share/classes/com/sun/media/sound/DataPusher.java
! src/share/classes/com/sun/media/sound/ModelStandardDirector.java
! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftMixingClip.java
! src/share/classes/sun/audio/AudioData.java

Changeset: fefa29e15a14
Author:    lana
Date:      2013-08-20 17:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fefa29e15a14

Merge


Changeset: 0beaa65c90c8
Author:    okutsu
Date:      2013-08-08 13:51 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0beaa65c90c8

8015986: Incorrect Localization of HijrahChronology
Reviewed-by: naoto
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com

! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/CalendarType.java
! src/share/classes/sun/text/resources/FormatData.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java

Changeset: 2c4f1081a0fa
Author:    uta
Date:      2013-08-08 09:16 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2c4f1081a0fa

7147084: (process) appA hangs when read output stream of appB which starts appC that runs forever
Reviewed-by: alanb, robm, martin

! src/windows/classes/java/lang/ProcessImpl.java
! src/windows/native/java/lang/ProcessImpl_md.c
+ test/java/lang/ProcessBuilder/InheritIOEHandle.java
+ test/java/lang/ProcessBuilder/SiblingIOEHandle.java

Changeset: b7d594716f86
Author:    weijun
Date:      2013-08-08 21:13 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b7d594716f86

8016594: Native Windows ccache still reads DES tickets
Reviewed-by: dsamersoff, xuelei

! src/share/classes/sun/security/krb5/Credentials.java
! src/share/native/sun/security/krb5/nativeccache.c
! src/windows/native/sun/security/krb5/NativeCreds.c

Changeset: a388263a7287
Author:    sherman
Date:      2013-08-08 12:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a388263a7287

8015666: test/tools/pack200/TimeStamp.java failing
Summary: to keep the default behavior of ZOS unchanged, if ze extra time not explicitly set
Reviewed-by: alanb, ksrini

! src/share/classes/java/util/zip/ZipConstants.java
! src/share/classes/java/util/zip/ZipEntry.java
! src/share/classes/java/util/zip/ZipFile.java
! src/share/classes/java/util/zip/ZipInputStream.java
! src/share/classes/java/util/zip/ZipOutputStream.java
! src/share/classes/java/util/zip/ZipUtils.java
! test/ProblemList.txt
! test/java/util/zip/TestExtraTime.java
! test/tools/pack200/TimeStamp.java

Changeset: 67edbf7e6b26
Author:    juh
Date:      2013-08-08 17:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/67edbf7e6b26

8022461: Fix lint warnings in sun.security.{provider,rsa,x509}
Reviewed-by: darcy, weijun, xuelei, mullan

! src/share/classes/sun/security/provider/DSAPublicKey.java
! src/share/classes/sun/security/rsa/RSAPublicKeyImpl.java
! src/share/classes/sun/security/rsa/RSASignature.java
! src/share/classes/sun/security/x509/AlgIdDSA.java
! src/share/classes/sun/security/x509/X509Key.java

Changeset: 758e3117899c
Author:    weijun
Date:      2013-08-09 11:41 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/758e3117899c

8021788: JarInputStream doesn't provide certificates for some file under META-INF
Reviewed-by: chegar, sherman

! src/share/classes/java/util/jar/JarVerifier.java
+ test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java

Changeset: 54f0ccdd9ad7
Author:    sherman
Date:      2013-08-08 23:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/54f0ccdd9ad7

6614237: missing codepage Cp290 at java runtime
Summary: to add charset Cp290 and Cp300
Reviewed-by: okutsu

+ make/tools/CharsetMapping/IBM290.c2b
+ make/tools/CharsetMapping/IBM290.map
+ make/tools/CharsetMapping/IBM300.c2b
+ make/tools/CharsetMapping/IBM300.map
! make/tools/CharsetMapping/dbcs
! make/tools/CharsetMapping/extsbcs
! make/tools/src/build/tools/charsetmapping/DBCS.java
! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java

Changeset: c29ca19cb816
Author:    psandoz
Date:      2013-08-09 11:44 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c29ca19cb816

8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED
Reviewed-by: martin, chegar

! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java

Changeset: 84004d0e3fdd
Author:    chegar
Date:      2013-08-09 13:50 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/84004d0e3fdd

8022661: InetAddress.writeObject() performs flush() on object output stream
Reviewed-by: michaelm, alanb

! src/share/classes/java/net/InetAddress.java

Changeset: ce1c874903cb
Author:    dl
Date:      2013-08-09 17:56 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ce1c874903cb

8022724: lint warnings in j.u.concurrent packages
Reviewed-by: chegar, lancea, darcy

! src/share/classes/java/util/concurrent/CompletableFuture.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/atomic/Striped64.java

Changeset: 03822f2389bf
Author:    dxu
Date:      2013-08-09 10:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/03822f2389bf

8021977: Opening a file using java.io can throw IOException on Windows
Summary: Remove IOException related error-handling code for backward compatibility
Reviewed-by: alanb, lancea, mr

! src/windows/native/java/io/io_util_md.c

Changeset: a7c341f30747
Author:    sherman
Date:      2013-08-09 12:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a7c341f30747

8020054: (tz) Support tzdata2013d
Summary: update the jdk8 tz data to version 2013d
Reviewed-by: coffeys, peytoia

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/antarctica
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/etcetera
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/factory
! make/sun/javazic/tzdata/iso3166.tab
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/pacificnew
! make/sun/javazic/tzdata/solar87
! make/sun/javazic/tzdata/solar88
! make/sun/javazic/tzdata/solar89
! make/sun/javazic/tzdata/southamerica
! make/sun/javazic/tzdata/systemv
! make/sun/javazic/tzdata/zone.tab
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/antarctica
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/australasia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/etcetera
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/factory
! test/sun/util/calendar/zi/tzdata/iso3166.tab
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/pacificnew
! test/sun/util/calendar/zi/tzdata/solar87
! test/sun/util/calendar/zi/tzdata/solar88
! test/sun/util/calendar/zi/tzdata/solar89
! test/sun/util/calendar/zi/tzdata/southamerica
! test/sun/util/calendar/zi/tzdata/systemv
! test/sun/util/calendar/zi/tzdata/zone.tab

Changeset: 8f01ccb0c981
Author:    joehw
Date:      2013-08-09 12:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8f01ccb0c981

8022548: SPECJVM2008 has errors introduced in 7u40-b34
Reviewed-by: chegar, lancea

+ test/javax/xml/jaxp/parsers/8022548/JDK8022548.xml
+ test/javax/xml/jaxp/parsers/8022548/JDK8022548.xsl
+ test/javax/xml/jaxp/parsers/8022548/TestBase.java
+ test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java

Changeset: ea4f4164422e
Author:    xuelei
Date:      2013-08-11 18:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ea4f4164422e

8022487: DEREncodedKeyValue.supportedKeyTypes should be private
Reviewed-by: mullan

! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java

Changeset: ffacf3e7a130
Author:    mullan
Date:      2013-08-12 09:03 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ffacf3e7a130

8016848: javax_security/auth/login tests fail in compact 1 and 2 profiles
Summary: Change the default value of the "login.configuration.provider" security property to sun.security.provider.ConfigFile
Reviewed-by: xuelei

! src/share/classes/com/sun/security/auth/login/ConfigFile.java
! src/share/classes/javax/security/auth/login/Configuration.java
+ src/share/classes/sun/security/provider/ConfigFile.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
! src/share/classes/sun/security/provider/SunEntries.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: d73fbf005f5f
Author:    mullan
Date:      2013-08-12 09:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d73fbf005f5f

Merge

- src/share/classes/java/net/package.html
- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: 70c8f4a4b8d6
Author:    vromero
Date:      2013-08-12 17:40 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/70c8f4a4b8d6

8015780: java/lang/reflect/Method/GenericStringTest.java failing
Reviewed-by: darcy, jfranck

! test/ProblemList.txt
! test/java/lang/reflect/Method/GenericStringTest.java

Changeset: 7758bcf0ab6b
Author:    henryjen
Date:      2013-08-12 12:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7758bcf0ab6b

8022749: Convert junit tests to testng in test/java/lang/invoke
Reviewed-by: mduigou, alanb
Contributed-by: Mani Sarkar <sadhak001 at gmail.com>

! test/java/lang/invoke/AccessControlTest.java
! test/java/lang/invoke/ClassValueTest.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/lang/invoke/PermuteArgsTest.java
! test/java/lang/invoke/ThrowExceptionsTest.java

Changeset: cc64a05836a7
Author:    lancea
Date:      2013-08-12 16:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cc64a05836a7

8022753: SQLXML javadoc example typo
Reviewed-by: alanb, mchung

! src/share/classes/java/sql/SQLXML.java

Changeset: 5b14d702b0b8
Author:    ascarpino
Date:      2013-08-12 11:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5b14d702b0b8

8020081: Cipher with OAEPPadding and OAEPParameterSpec can't be created
Reviewed-by: mullan

! src/share/classes/com/sun/crypto/provider/SunJCE.java
+ test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java

Changeset: 818c3f82269c
Author:    vinnie
Date:      2013-08-13 14:15 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/818c3f82269c

8013170: Spec for PBEParameterSpec does not specify behavior when paramSpec is null
Reviewed-by: mullan

! src/share/classes/javax/crypto/spec/PBEParameterSpec.java

Changeset: 26753a05859a
Author:    vinnie
Date:      2013-08-13 14:18 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/26753a05859a

Merge


Changeset: 834faf2081b3
Author:    bpb
Date:      2013-08-12 16:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/834faf2081b3

8022180: BigInteger Burnikel-Ziegler quotient and remainder calculation assumes quotient parameter is zero
Summary: Clear the quotient in divideAndRemainderBurnikelZiegler() if the divisor is larger than the dividend.
Reviewed-by: alanb, bpb
Contributed-by: Timothy Buktu <tbuktu at hotmail.com>

! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java

Changeset: 18e15d92610b
Author:    chegar
Date:      2013-08-13 14:57 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/18e15d92610b

8022779: ProblemList.txt updates (8/2013)
Summary: Update ProblemList and remove AggressiveOpts MOAT test run
Reviewed-by: chegar, alanb
Contributed-by: Amy Lu <amy.lu at oracle.com>

! test/ProblemList.txt
! test/java/util/Collection/MOAT.java

Changeset: 78c102c3eefc
Author:    dfuchs
Date:      2013-08-13 16:00 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/78c102c3eefc

8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is failing intermittently
Reviewed-by: mchung, dholmes

! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java

Changeset: 412b2f0950a9
Author:    mullan
Date:      2013-08-13 10:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/412b2f0950a9

8022897: Add test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java to ProblemList
Reviewed-by: vinnie, chegar

! test/ProblemList.txt

Changeset: 19133b3af95f
Author:    mullan
Date:      2013-08-13 10:07 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/19133b3af95f

Merge

! test/ProblemList.txt

Changeset: cd9379e348d0
Author:    darcy
Date:      2013-08-13 10:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cd9379e348d0

8022959: Fix new doclint issues in java.util.zip
Reviewed-by: chegar

! src/share/classes/java/util/zip/ZipEntry.java

Changeset: a4b0be7341ef
Author:    robm
Date:      2013-08-13 19:10 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a4b0be7341ef

5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
Reviewed-by: alanb, dholmes, martin, erikj, coffeys

! make/java/java/Exportedfiles.gmk
! make/java/java/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
! src/solaris/classes/java/lang/UNIXProcess.java.solaris
! src/solaris/native/java/lang/UNIXProcess_md.c
+ src/solaris/native/java/lang/childproc.c
+ src/solaris/native/java/lang/childproc.h
+ src/solaris/native/java/lang/jspawnhelper.c
! test/java/lang/ProcessBuilder/Basic.java

Changeset: 18ce880b5fb4
Author:    lana
Date:      2013-08-13 18:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/18ce880b5fb4

Merge

! makefiles/CompileNativeLibraries.gmk

Changeset: cb74d71fd02f
Author:    hseigel
Date:      2013-08-13 10:56 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cb74d71fd02f

8022259: MakeClasslist is buggy and its README is out of date.
Summary: Fixed bug in FOR loop and updated comments and README
Reviewed-by: dholmes, alanb

! make/tools/sharing/README.txt
! make/tools/src/build/tools/makeclasslist/MakeClasslist.java

Changeset: f9cf6ecf596c
Author:    coleenp
Date:      2013-08-14 10:14 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f9cf6ecf596c

Merge


Changeset: bc3cafb17c09
Author:    ksrini
Date:      2013-08-14 08:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bc3cafb17c09

8022547: [verifier] move DefaultMethodRegressionTests.java to jdk
Reviewed-by: acorn

+ test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java
+ test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java

Changeset: 444a7edcf367
Author:    darcy
Date:      2013-08-14 11:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/444a7edcf367

8022990: Fix dep_ann lint warnings in swing code
Reviewed-by: alexsch

! src/share/classes/com/sun/java/swing/Painter.java
! src/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java
! src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java

Changeset: c138d1b608e0
Author:    sherman
Date:      2013-08-14 11:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c138d1b608e0

8022178: System.console() throws IOE on some Windows
Summary: to remove the IOE throwing code
Reviewed-by: alanb

! src/windows/native/java/io/Console_md.c

Changeset: 17dfbb3f60d3
Author:    bpb
Date:      2013-08-12 10:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/17dfbb3f60d3

8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math
Summary: Add the methods for parameter types int and long.
Reviewed-by: mduigou
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! src/share/classes/java/lang/Math.java
! test/java/lang/Math/ExactArithTests.java

Changeset: f8af3499c1fb
Author:    wetmore
Date:      2013-08-14 19:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f8af3499c1fb

8023075: JDK-5049299 has broken old make in jdk8
Reviewed-by: katleman

! make/java/java/Makefile

Changeset: 2f6523abab08
Author:    yhuang
Date:      2013-08-14 22:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2f6523abab08

8021121: ISO 4217 Amendment Number 156
Reviewed-by: naoto

! src/share/classes/java/util/CurrencyData.properties
! src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties
! test/java/util/Currency/tablea1.txt
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: 5ff3b55df2d4
Author:    alanb
Date:      2013-08-15 11:54 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5ff3b55df2d4

8022921: Remove experimental Profile attribute
Reviewed-by: mchung, chegar

! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/util/jar/Attributes.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
! src/share/classes/sun/launcher/LauncherHelper.java
! src/share/classes/sun/launcher/resources/launcher.properties
! src/share/classes/sun/misc/JavaUtilJarAccess.java
! src/share/classes/sun/misc/URLClassPath.java
! src/share/classes/sun/misc/Version.java.template
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/resources/jar.properties
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java

Changeset: b7b0beef5ded
Author:    alanb
Date:      2013-08-15 13:42 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b7b0beef5ded

8015765: TEST_BUG: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failing intermittently
Reviewed-by: chegar, dholmes, alanb
Contributed-by: yiming.wang at oracle.com

! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java

Changeset: 7d7d553a8c61
Author:    igerasim
Date:      2013-08-13 13:04 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7d7d553a8c61

8022584: Memory leak in some NetworkInterface methods
Reviewed-by: alanb, dholmes, chegar, michaelm

! src/solaris/native/java/net/NetworkInterface.c
+ test/java/net/NetworkInterface/MemLeakTest.java

Changeset: 3223342fb76e
Author:    dl
Date:      2013-08-15 15:01 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3223342fb76e

8023103: FJ parallelism zero
8020537: java/util/concurrent/forkjoin/ThrowingRunnable.java
Reviewed-by: chegar, mduigou, alanb

! src/share/classes/java/util/concurrent/ForkJoinPool.java

Changeset: b07b19182e40
Author:    dl
Date:      2013-08-15 15:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b07b19182e40

8023104: ConcurrentHashMap typo
Reviewed-by: chegar, mduigou

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java

Changeset: e7137695dce3
Author:    chegar
Date:      2013-08-15 15:16 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e7137695dce3

8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress
Reviewed-by: smarks, alanb, michaelm, darcy

! src/share/classes/java/net/DatagramPacket.java

Changeset: 6c307b4d0dd8
Author:    sherman
Date:      2013-08-15 10:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6c307b4d0dd8

7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException
Summary: to add the throws clause
Reviewed-by: alanb, chegar

! src/share/classes/java/util/zip/Adler32.java
! src/share/classes/java/util/zip/CRC32.java

Changeset: b4645069238a
Author:    vinnie
Date:      2013-08-15 19:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b4645069238a

8023108: Remove ShortRSAKey1024.sh from ProblemList.txt
Reviewed-by: mullan

! test/ProblemList.txt

Changeset: 3211caab58ba
Author:    vinnie
Date:      2013-08-15 19:56 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3211caab58ba

Merge


Changeset: 5bb196aa183c
Author:    dxu
Date:      2013-08-15 12:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5bb196aa183c

4858457: File.getCanonicalPath() throws IOException when invoked with "nul" (win)
Reviewed-by: alanb

! src/windows/native/java/io/canonicalize_md.c
! test/java/io/File/WinDeviceName.java

Changeset: 0d27309a87e0
Author:    dxu
Date:      2013-08-15 14:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0d27309a87e0

8017109: Cleanup overrides warning in src/solaris/classes/sun/print/AttributeClass.java
Reviewed-by: jgodinez

! src/solaris/classes/sun/print/AttributeClass.java

Changeset: 5649837a4cfa
Author:    briangoetz
Date:      2013-08-12 12:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5649837a4cfa

8019401: Collectors.collectingAndThen
Reviewed-by: mduigou
Contributed-by: brian.goetz at oracle.com

! src/share/classes/java/util/stream/Collectors.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java

Changeset: 5fe19566b6f0
Author:    psandoz
Date:      2013-08-16 12:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5fe19566b6f0

8023150: java/util/stream tests no longer compiling following JDK-8019401
Reviewed-by: alanb

! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java

Changeset: 2eebaff52a94
Author:    psandoz
Date:      2013-08-16 12:46 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2eebaff52a94

8012940: More than 50 tests failed in Serialization/DeSerialization testing (test-mangled)
Reviewed-by: ksrini

+ test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
! test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java

Changeset: 02ce5a0e4b98
Author:    psandoz
Date:      2013-08-16 12:46 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/02ce5a0e4b98

8022898: java/util/Spliterator/SpliteratorCollisions.java fails in HashableIntSpliteratorWithNull data provider
Reviewed-by: henryjen, alanb, rriggs

! test/java/util/Spliterator/SpliteratorCollisions.java

Changeset: 737b6c298d81
Author:    psandoz
Date:      2013-08-13 11:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/737b6c298d81

8022797: Clarify spliterator characteristics for collections containing no elements
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Collection.java

Changeset: 53819fd0ab61
Author:    rriggs
Date:      2013-08-16 11:28 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/53819fd0ab61

8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing
8022766: java/time/test/java/time/chrono/TestUmmAlQuraChronology.java failed.
Summary: TCKChronology: corrected display name to match update from JDK-8015986
Reviewed-by: alanb

! test/java/time/tck/java/time/chrono/TCKChronology.java
! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java

Changeset: d7fc4e149bb8
Author:    rriggs
Date:      2013-08-16 11:11 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d7fc4e149bb8

8022193: java/time/test/java/util/TestFormatter.java failed in th locale.
Summary: Tests corrected to use fixed locale and not dependent on the environment
Reviewed-by: sherman

! src/share/classes/java/util/Formatter.java
! test/java/time/test/java/util/TestFormatter.java

Changeset: acaa256e3f7c
Author:    rriggs
Date:      2013-08-16 13:58 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/acaa256e3f7c

8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate
Summary: align Meiji start date with lib/calendar.properties to avoid any confusion
Reviewed-by: sherman

! src/share/classes/java/time/chrono/JapaneseEra.java

Changeset: 9e9f5713b26d
Author:    psandoz
Date:      2013-08-06 14:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9e9f5713b26d

8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls
Reviewed-by: chegar
Contributed-by: Martin Buchholz <martinrb at google.com>, Paul Sandoz <paul.sandoz at oracle.com>

! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/concurrent/package-info.java

Changeset: 8e098a29ecd8
Author:    egahlin
Date:      2013-08-16 17:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8e098a29ecd8

6417702: Graph in Memory tab is not redrawn immediately if changed via 'Chart' combo box
Reviewed-by: alanb, jbachorik, sjiang

! src/share/classes/sun/tools/jconsole/MemoryTab.java

Changeset: c67cb9d4d51a
Author:    egahlin
Date:      2013-08-16 17:11 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c67cb9d4d51a

6721425: jconsole Makefile clean rule is missing rm of generated Version.java
Reviewed-by: alanb, jbachorik

! make/sun/jconsole/Makefile

Changeset: 89ef4bcf7b0e
Author:    egahlin
Date:      2013-08-16 16:53 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/89ef4bcf7b0e

7015157: String "Tabular Navigation" should be rephrased for avoiding mistranslation
Reviewed-by: alanb, jbachorik, sjiang

! src/share/classes/sun/tools/jconsole/resources/messages.properties

Changeset: 71bad9540825
Author:    egahlin
Date:      2013-08-16 18:58 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/71bad9540825

6696970: Jconsole becomes unusable if a plugin throws an exception
Reviewed-by: mchung, jbachorik

+ src/share/classes/sun/tools/jconsole/ExceptionSafePlugin.java
! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/VMPanel.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties

Changeset: 11ccaabdb2a8
Author:    aefimov
Date:      2013-08-16 18:41 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/11ccaabdb2a8

8021820: Number of opened files used in select() is limited to 1024 [macosx]
Reviewed-by: alanb, chegar, tbell, smarks

+ test/java/net/ServerSocket/SelectFdsLimit.java

Changeset: f580728b08b4
Author:    alanb
Date:      2013-08-19 11:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f580728b08b4

8023215: test/java/util/Comparator/TypeTest.java not running (failing but reported as passing)
Reviewed-by: psandoz

! test/java/util/Comparator/TypeTest.java

Changeset: 3647aab7b1d5
Author:    psandoz
Date:      2013-08-06 14:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3647aab7b1d5

8014824: Document Spliterator characteristics and binding policy of java util collection impls
Reviewed-by: chegar

! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/LinkedHashMap.java
! src/share/classes/java/util/LinkedHashSet.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java

Changeset: bce5205dbe84
Author:    ascarpino
Date:      2013-08-14 10:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bce5205dbe84

8022669: OAEPParameterSpec does not work if MGF1ParameterSpec is set to SHA2 algorithms
Reviewed-by: mullan

! src/share/classes/sun/security/rsa/RSAPadding.java
! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java

Changeset: b40d246d4d81
Author:    ascarpino
Date:      2013-08-16 12:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b40d246d4d81

8022896: test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java fails
Reviewed-by: mullan

! test/ProblemList.txt

Changeset: 2fd841fccb2e
Author:    dxu
Date:      2013-08-19 12:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2fd841fccb2e

8023203: Wrap RandomAccessFile.seek native method into a Java helper method
Reviewed-by: alanb, chegar

! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/share/classes/java/io/RandomAccessFile.java
! src/share/native/java/io/RandomAccessFile.c

Changeset: f120e2c4b4b1
Author:    mullan
Date:      2013-08-19 17:17 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f120e2c4b4b1

8016850: JCK javax.security.auth.Policy tests fail when run in Profiles mode
Summary: Move default javax.security.auth.Policy implementation to compact1 profile
Reviewed-by: vinnie

! src/share/classes/com/sun/security/auth/PolicyFile.java
- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
! src/share/classes/javax/security/auth/Policy.java
+ src/share/classes/sun/security/provider/AuthPolicyFile.java
+ src/share/classes/sun/security/provider/SubjectCodeSource.java

Changeset: 096e7c665857
Author:    xuelei
Date:      2013-08-19 17:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/096e7c665857

8020842: IDN do not throw IAE when hostname ends with a trailing dot
Reviewed-by: weijun, michaelm

! src/share/classes/java/net/IDN.java
+ test/java/net/IDN/IllegalArg.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java

Changeset: 21a25911f7f7
Author:    xuelei
Date:      2013-08-19 18:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/21a25911f7f7

8023230: The impl of KerberosClientKeyExchange maybe not exist
Reviewed-by: weijun

! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java

Changeset: 53ea4b5cef9b
Author:    sla
Date:      2013-08-20 08:59 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/53ea4b5cef9b

8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual machine
Reviewed-by: erikj, sspitsyn

! makefiles/CompileNativeLibraries.gmk
+ makefiles/mapfiles/libattach/reorder-windows-x86
+ makefiles/mapfiles/libattach/reorder-windows-x86_64
! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c

Changeset: e17da8b09f5e
Author:    dholmes
Date:      2013-08-20 03:18 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e17da8b09f5e

8023311: Clean up profile-includes.txt
Reviewed-by: alanb

! makefiles/profile-includes.txt

Changeset: 961cdea684b5
Author:    sla
Date:      2013-08-20 16:53 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/961cdea684b5

8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently
Reviewed-by: alanb

! test/com/sun/jdi/sde/TemperatureTableTest.java

Changeset: c17d6543b30f
Author:    psandoz
Date:      2013-08-20 17:36 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c17d6543b30f

8023367: Collections.emptyList().sort((Comparator)null) throws NPE
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Collections.java
! test/java/util/Collection/ListDefaults.java

Changeset: 1ccc7bbee0bb
Author:    attila
Date:      2013-08-20 11:15 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1ccc7bbee0bb

8023250: Update JavaScript code in JDK for changes in iteration over Java arrays
Reviewed-by: sundar, sla

! src/share/classes/com/sun/tools/hat/resources/hat.js

Changeset: a79fcf53195f
Author:    lana
Date:      2013-08-20 17:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a79fcf53195f

Merge

- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java

Changeset: 9626ba160e3d
Author:    lana
Date:      2013-08-23 14:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9626ba160e3d

Merge

- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java

Changeset: 0417358184a1
Author:    omajid
Date:      2013-08-22 16:00 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0417358184a1

8023480: Create a jvm.cfg for zero on 32 bit architectures
Reviewed-by: dholmes, erikj

! makefiles/CopyFiles.gmk

Changeset: 1fe211ae3d2b
Author:    katleman
Date:      2013-08-26 17:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1fe211ae3d2b

Merge


Changeset: 1a2a8d143583
Author:    cl
Date:      2013-08-29 09:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1a2a8d143583

Added tag jdk8-b105 for changeset 1fe211ae3d2b

! .hgtags


From vladimir.kozlov at oracle.com  Thu Aug 29 12:33:59 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 29 Aug 2013 12:33:59 -0700
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F9EE2.2000403@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521F97EE.9060407@oracle.com> <521F9EE2.2000403@oracle.com>
Message-ID: <521FA227.3000305@oracle.com>

Lois,

On 8/29/13 12:20 PM, Calvin Cheung wrote:
> Hi Lois,
>
> src/share/vm/code/nmethod.cpp
>
> 803 void* nmethod::operator new(size_t size, int nmethod_size) throw() {

Could you remove this throw()? As David pointed it was discussed and, we 
think, it was added by mistake.

thanks,
Vladimir

>
> The above line looks the same to me after the change.
> So perhaps the file doesn't need to be changed (other than the copyright
> year)?
>
> Calvin
>
> On 8/29/2013 11:50 AM, Coleen Phillimore wrote:
>>
>> Lois,
>>
>> This does looks better than the NOEXCEPT macros.  Can other people
>> review this today?  We need this for the clang c++ compiler upgrade
>> testing.
>>
>> Thanks,
>> Coleen
>>
>> On 08/29/2013 02:33 PM, Lois Foltan wrote:
>>>
>>> Please review the following updated webrev:
>>>
>>> Internal webrev:
>>>
>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>>>
>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>>          runtime/6878713/Test6878713.sh fails on mac
>>>
>>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>
>>> Summary of fix:
>>>     On MacOS, currently Hotspot is built specifying the -fcheck-new
>>> command line option to the llvm-g++ compiler.
>>>     The -fcheck-new option directs the compiler to "check that the
>>> pointer returned by |operator new| is non-null
>>>      before attempting to modify the storage allocated."  The clang++
>>> compiler does not support the
>>>      -fcheck-new option.  To obtain similiar functionality when
>>> building Hotspot with clang++, empty exception
>>>      throw() specifications must be added to all user-defined
>>> operator new()'s.
>>>
>>> Tests:
>>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010,
>>> MacOS (llvm-g++ & clang++)
>>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>>
>>> Original Testing:
>>>      Solaris: built fastdebug & product images
>>>      Linux: built fastdebug & product images
>>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>>                     built fastdebug & product images using clang++ -
>>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>>      Windows:  built fastdebug & product images with VS2010
>>>
>>> Thank you,
>>> Lois
>>>
>>
>

From john.coomes at oracle.com  Thu Aug 29 12:36:39 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 19:36:39 +0000
Subject: hg: hsx/hotspot-emb/langtools: 29 new changesets
Message-ID: <20130829193813.55439623DE@hg.openjdk.java.net>

Changeset: b8610a65fbf9
Author:    vromero
Date:      2013-08-08 11:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/b8610a65fbf9

8019486: javac, generates erroneous LVT for a test case with lambda code
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/T8019486/WrongLVTForLambdaTest.java

Changeset: d601238641e6
Author:    ksrini
Date:      2013-08-09 15:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/d601238641e6

8022161: javac Null Pointer Exception in Enter.visitTopLevel
Reviewed-by: jjg, vromero, jlahoda

! src/share/classes/com/sun/tools/javac/comp/Enter.java
! test/tools/javac/TestPkgInfo.java

Changeset: 0d9bc764cac7
Author:    vromero
Date:      2013-08-10 13:27 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/0d9bc764cac7

8009640: -profile <compact> does not work when -bootclasspath specified
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java

Changeset: 8f282dc58dfc
Author:    vromero
Date:      2013-08-10 16:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/8f282dc58dfc

8022622: javac, two tests are failing with compile time error after class Collector was modified
Reviewed-by: mcimadamore

! test/tools/javac/lambda/TargetType59.java
! test/tools/javac/lambda/TargetType62.java

Changeset: aa6c6f8b5622
Author:    vromero
Date:      2013-08-10 16:29 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/aa6c6f8b5622

6983297: methods missing from NewArrayTree
Reviewed-by: jjg

! src/share/classes/com/sun/source/tree/NewArrayTree.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! test/tools/javac/tree/SourceTreeScannerTest.java

Changeset: f7f271bd74a2
Author:    mcimadamore
Date:      2013-08-12 17:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f7f271bd74a2

6537020: JCK tests: a compile-time error should be given in case of ambiguously imported fields (types, methods)
Summary: Hiding check does not support interface multiple inheritance
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/4980495/static/Test.out
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java
+ test/tools/javac/staticImport/6537020/T6537020.java
+ test/tools/javac/staticImport/6537020/T6537020.out

Changeset: af80273f630a
Author:    mcimadamore
Date:      2013-08-12 17:28 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/af80273f630a

8021567: Javac doesn't report \"java: reference to method is ambiguous\" any more
Summary: Javac incorrectly forgets about constant folding results within lambdas
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/8021567/T8021567.java
+ test/tools/javac/lambda/8021567/T8021567.out
+ test/tools/javac/lambda/8021567/T8021567b.java

Changeset: 32b6a99cc74e
Author:    lana
Date:      2013-08-13 18:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/32b6a99cc74e

Merge


Changeset: 0ad781399706
Author:    vromero
Date:      2013-08-14 10:53 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/0ad781399706

8013394: compile of iterator use fails with error \"defined in an inaccessible class or interface\"
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T8013394/CompileErrorWithIteratorTest.java

Changeset: 3ab468194f11
Author:    ksrini
Date:      2013-08-14 07:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/3ab468194f11

8007517: DefaultMethodRegressionTests.java fail in TL
Reviewed-by: jjg, vromero

- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java

Changeset: 14faef2b51eb
Author:    jjg
Date:      2013-08-14 16:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/14faef2b51eb

8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
+ test/com/sun/javadoc/testSeeTag/TestSeeTag.java
+ test/com/sun/javadoc/testSeeTag/pkg/Test.java

Changeset: fac0d1bb87f2
Author:    ksrini
Date:      2013-08-14 18:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/fac0d1bb87f2

6840442: JavaCompiler.getTask() has incomplete specification for IllegalArgumentException
Reviewed-by: jjg

! src/share/classes/javax/tools/JavaCompiler.java

Changeset: 3d4f0fa2ad05
Author:    bpatel
Date:      2013-08-14 21:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/3d4f0fa2ad05

8016921: Change the profiles table on overview-summary.html page to a list
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java

Changeset: 71b0089b146f
Author:    erikj
Date:      2013-08-15 17:24 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/71b0089b146f

8015145: Smartjavac needs more flexibility with linking to sources
Reviewed-by: jjg, ohrstrom

! src/share/classes/com/sun/tools/sjavac/JavacState.java
! src/share/classes/com/sun/tools/sjavac/Main.java
! test/tools/sjavac/SJavac.java

Changeset: a6378c19836b
Author:    vromero
Date:      2013-08-16 10:32 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/a6378c19836b

8022053: javac generates unverifiable initializer for nested subclass of local class
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T8022053/UnverifiableInitForNestedLocalClassTest.java

Changeset: ec77c7b46c37
Author:    jlahoda
Date:      2013-08-15 22:33 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/ec77c7b46c37

8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression
Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java
+ test/tools/javac/lambda/ExceptionsInLambda.java
+ test/tools/javac/lambda/ExceptionsInLambda.out
! test/tools/javac/lambda/TargetType21.out

Changeset: f657d400c736
Author:    jlahoda
Date:      2013-08-15 22:36 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f657d400c736

8022508: javac crashes if the generics arity of a base class is wrong
Reviewed-by: mcimadamore, vromero

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/generics/8016640/T8016640.java

Changeset: 4300c2f5fb1b
Author:    erikj
Date:      2013-08-16 16:00 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/4300c2f5fb1b

8023146: Sjavac test failes in langtools nightly
Reviewed-by: mcimadamore, jfranck

! test/tools/sjavac/SJavac.java

Changeset: 389eaf6ed973
Author:    ksrini
Date:      2013-08-19 07:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/389eaf6ed973

7071377: Exception when javac -processor is given a class name with invalid postfix
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/processing/errors/TestClassNames.java

Changeset: 55da6b3a6940
Author:    kizune
Date:      2013-08-20 17:34 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/55da6b3a6940

7182350: Regression in wording of unchecked warning message
Reviewed-by: mcimadamore, jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/6758789/T6758789b.out
+ test/tools/javac/7182350/T7182350.java
+ test/tools/javac/7182350/T7182350.out
! test/tools/javac/generics/7015430/T7015430_1.out
! test/tools/javac/generics/7015430/T7015430_2.out
! test/tools/javac/generics/7151802/T7151802.out
! test/tools/javac/generics/inference/6718364/T6718364.out
! test/tools/javac/generics/inference/7177306/T7177306a.out

Changeset: e811fb09a1dc
Author:    jfranck
Date:      2013-08-20 17:21 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/e811fb09a1dc

8019243: AnnotationTypeMismatchException instead of MirroredTypeException
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
+ test/tools/javac/processing/errors/EnsureMirroredTypeException/Processor.java
+ test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.java
+ test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.out

Changeset: 58da1296c6b3
Author:    darcy
Date:      2013-08-20 12:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/58da1296c6b3

8011043: Warn about use of 1.5 and earlier source and target values
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javadoc/Start.java
+ test/tools/javac/diags/examples/ObsoleteSourceAndTarget.java

Changeset: 0f88e3d3d250
Author:    ksrini
Date:      2013-08-20 14:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/0f88e3d3d250

7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against JDK 7 and JDK 8
Reviewed-by: jjg

! test/tools/javac/processing/model/testgetallmembers/Main.java

Changeset: a76dc1b4c299
Author:    jjg
Date:      2013-08-20 14:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/a76dc1b4c299

8020663: Restructure some properties to facilitate better translation
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java

Changeset: 79e341614c50
Author:    jjg
Date:      2013-08-20 14:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/79e341614c50

8022080: javadoc generates invalid HTML in Turkish locale
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java
! src/share/classes/com/sun/tools/doclint/HtmlTag.java

Changeset: 720992953d43
Author:    jjg
Date:      2013-08-20 15:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/720992953d43

8013887: In class use, some tables are randomly unsorted
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java

Changeset: b59a0b4675c9
Author:    lana
Date:      2013-08-20 17:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/b59a0b4675c9

Merge

- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java

Changeset: 375834b5cf08
Author:    lana
Date:      2013-08-23 14:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/375834b5cf08

Merge

- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java

Changeset: e431c9bfb171
Author:    cl
Date:      2013-08-29 09:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/e431c9bfb171

Added tag jdk8-b105 for changeset 375834b5cf08

! .hgtags


From john.coomes at oracle.com  Thu Aug 29 12:38:30 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 19:38:30 +0000
Subject: hg: hsx/hotspot-emb/nashorn: 23 new changesets
Message-ID: <20130829193852.26A00623DF@hg.openjdk.java.net>

Changeset: 9a3e3bb30db3
Author:    attila
Date:      2013-08-07 16:38 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/9a3e3bb30db3

8022509: Various Dynalink security enhancements
Reviewed-by: jlaskey, hannesw

! src/jdk/internal/dynalink/ChainedCallSite.java
! src/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk/internal/dynalink/beans/ClassString.java
! src/jdk/internal/dynalink/beans/StaticClassLinker.java
- src/jdk/internal/dynalink/support/Backport.java
! src/jdk/internal/dynalink/support/ClassMap.java
! src/jdk/internal/dynalink/support/Guards.java
! src/jdk/internal/dynalink/support/Lookup.java
! src/jdk/internal/dynalink/support/TypeConverterFactory.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java

Changeset: dd79c04ef7df
Author:    sundar
Date:      2013-08-08 16:38 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/dd79c04ef7df

8022524: Memory leaks in nashorn sources and tests found by jhat analysis
Reviewed-by: attila, hannesw

! make/project.properties
! src/jdk/nashorn/internal/codegen/CompileUnit.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeDate.java
! src/jdk/nashorn/internal/objects/NativeJSON.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/GlobalObject.java
! src/jdk/nashorn/internal/runtime/JSONFunctions.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! test/script/basic/JDK-8020357.js
! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java
! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java
! test/src/jdk/nashorn/internal/codegen/CompilerTest.java
! test/src/jdk/nashorn/internal/parser/ParserTest.java

Changeset: 0d7484bf8597
Author:    sundar
Date:      2013-08-08 18:19 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/0d7484bf8597

Merge

- src/jdk/internal/dynalink/support/Backport.java

Changeset: 14ea21d58f83
Author:    jlaskey
Date:      2013-08-08 11:20 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/14ea21d58f83

Merge

- src/jdk/internal/dynalink/support/Backport.java

Changeset: 47e2b609fe31
Author:    sundar
Date:      2013-08-09 20:48 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/47e2b609fe31

8022707: Revisit all doPrivileged blocks
Reviewed-by: jlaskey, hannesw

! make/project.properties
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeDebug.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ECMAErrors.java
! src/jdk/nashorn/internal/runtime/Logging.java
! src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java
! src/jdk/nashorn/internal/runtime/options/Options.java
! src/jdk/nashorn/tools/Shell.java

Changeset: 01304b0550fb
Author:    sundar
Date:      2013-08-12 14:43 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/01304b0550fb

8022782: publicLookup access failures in ScriptObject, ScriptFunction and ScriptFunction
Reviewed-by: lagergren, attila, hannesw

! src/jdk/nashorn/internal/codegen/CompilerConstants.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java

Changeset: 3c13fba4d727
Author:    attila
Date:      2013-08-12 12:46 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/3c13fba4d727

8022789: Revisit doPrivileged blocks in Dynalink
Reviewed-by: lagergren, sundar

! src/jdk/internal/dynalink/DynamicLinkerFactory.java
+ src/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java
! src/jdk/internal/dynalink/support/ClassMap.java
! src/jdk/internal/dynalink/support/TypeConverterFactory.java

Changeset: 0bbaa0ac36ab
Author:    sundar
Date:      2013-08-12 16:52 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/0bbaa0ac36ab

8022614: Please exclude test test/script/trusted/JDK-8020809.js from Nashorn code coverage run
Reviewed-by: jlaskey, lagergren

! exclude/exclude_list_cc.txt

Changeset: 03ba1cd734c0
Author:    hannesw
Date:      2013-08-12 13:31 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/03ba1cd734c0

8022731: NativeArguments has wrong implementation of isMapped()
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeArguments.java
+ test/script/basic/JDK-8022731.js
+ test/script/basic/JDK-8022731.js.EXPECTED

Changeset: 821b605c7046
Author:    sundar
Date:      2013-08-12 17:08 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/821b605c7046

8022615: [nightly] Two nashorn print tests fail in nightly builds on Windows
Reviewed-by: lagergren, jlaskey

! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: f2e1673db03b
Author:    sundar
Date:      2013-08-12 18:16 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/f2e1673db03b

8022598: Object.getPrototypeOf should return null for host objects rather than throwing TypeError
Reviewed-by: lagergren, jlaskey, attila, hannesw

! src/jdk/nashorn/internal/objects/NativeObject.java
+ test/script/basic/JDK-8022598.js

Changeset: a0807e889be3
Author:    sundar
Date:      2013-08-12 20:37 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/a0807e889be3

Merge


Changeset: 8ecf68b292d0
Author:    lana
Date:      2013-08-13 18:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/8ecf68b292d0

Merge


Changeset: bbc4e9d37315
Author:    jlaskey
Date:      2013-08-12 18:00 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/bbc4e9d37315

8022676: Confusing error message checking instanceof non-class
Reviewed-by: jlaskey, sundar
Contributed-by: michael.horowitz at oracle.com

! src/jdk/nashorn/internal/runtime/resources/Messages.properties

Changeset: ba507ac08719
Author:    sundar
Date:      2013-08-14 20:51 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/ba507ac08719

8023026: Array.prototype iterator functions like forEach, reduce should work for Java arrays, lists
Reviewed-by: jlaskey, lagergren

- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/JavaListIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseJavaListIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseScriptArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ScriptArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ScriptObjectIterator.java
+ test/script/basic/JDK-8023026.js
+ test/script/basic/JDK-8023026.js.EXPECTED

Changeset: 09c99b58b81e
Author:    sundar
Date:      2013-08-16 15:04 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/09c99b58b81e

8020355: bind on built-in constructors don't use bound argument values
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
+ test/script/basic/JDK-8020355.js

Changeset: 1d29d2e27590
Author:    hannesw
Date:      2013-08-16 13:42 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/1d29d2e27590

8019985: Date.parse("2000-01-01T00:00:00.Z") should return NaN
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/parser/DateParser.java
+ test/script/basic/JDK-8019985.js

Changeset: 36fb36217e1d
Author:    lagergren
Date:      2013-08-16 18:51 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/36fb36217e1d

8023017: SUB missing for widest op == number for BinaryNode
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java
! src/jdk/nashorn/internal/codegen/ObjectCreator.java
! src/jdk/nashorn/internal/ir/BinaryNode.java
! src/jdk/nashorn/internal/ir/BreakableNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/LexicalContextNode.java
! src/jdk/nashorn/internal/objects/NativeArguments.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java
! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethod.java
! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java

Changeset: bd0174b1a42f
Author:    sundar
Date:      2013-08-19 17:16 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/bd0174b1a42f

8023210: jjs tools should support a mode where it will load few command line scripts and then entering into interactive shell
Reviewed-by: hannesw, attila, lagergren, jlaskey

! src/jdk/nashorn/internal/runtime/options/Options.java
! src/jdk/nashorn/tools/Shell.java

Changeset: e628aefac504
Author:    sundar
Date:      2013-08-19 19:37 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/e628aefac504

Merge

- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: 1f2394beecf7
Author:    lana
Date:      2013-08-20 17:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/1f2394beecf7

Merge

- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: f484bfb624dd
Author:    lana
Date:      2013-08-23 14:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/f484bfb624dd

Merge

- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: 824d33e678f2
Author:    cl
Date:      2013-08-29 09:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/nashorn/rev/824d33e678f2

Added tag jdk8-b105 for changeset f484bfb624dd

! .hgtags


From harold.seigel at oracle.com  Thu Aug 29 12:43:39 2013
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Thu, 29 Aug 2013 19:43:39 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022407: sun/misc/CopyMemory.java fails
	with SIGSEGV in Unsafe_SetByte+0x35
Message-ID: <20130829194344.EAEB7623E0@hg.openjdk.java.net>

Changeset: dfc126b2f659
Author:    hseigel
Date:      2013-08-29 13:44 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dfc126b2f659

8022407: sun/misc/CopyMemory.java fails with SIGSEGV in Unsafe_SetByte+0x35
Summary: lower optimization level for unsafe.cpp due to MacOS Xcode 4.6.2 compiler optimization issue.
Reviewed-by: coleenp, twisti, dholmes
Contributed-by: lois.foltan at oracle.com

! make/bsd/makefiles/gcc.make


From john.coomes at oracle.com  Thu Aug 29 13:31:05 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 20:31:05 +0000
Subject: hg: hsx/hotspot-rt/jaxp: 5 new changesets
Message-ID: <20130829203121.74AC0623ED@hg.openjdk.java.net>

Changeset: 4e23bc205d9d
Author:    joehw
Date:      2013-08-09 12:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/4e23bc205d9d

8022548: SPECJVM2008 has errors introduced in 7u40-b34
Reviewed-by: chegar, lancea

! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java
! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java
! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java

Changeset: 9800647936dd
Author:    lana
Date:      2013-08-13 18:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/9800647936dd

Merge


Changeset: d4d6422ec564
Author:    lana
Date:      2013-08-20 17:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/d4d6422ec564

Merge


Changeset: 09a46ec11f88
Author:    lana
Date:      2013-08-23 14:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/09a46ec11f88

Merge


Changeset: d3be8e3b429d
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/d3be8e3b429d

Added tag jdk8-b105 for changeset 09a46ec11f88

! .hgtags


From john.coomes at oracle.com  Thu Aug 29 13:30:39 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 20:30:39 +0000
Subject: hg: hsx/hotspot-rt: 6 new changesets
Message-ID: <20130829203040.3B627623EB@hg.openjdk.java.net>

Changeset: 00dcfaa6bc01
Author:    aefimov
Date:      2013-08-16 18:40 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/00dcfaa6bc01

8021820: Number of opened files used in select() is limited to 1024 [macosx]
Reviewed-by: alanb, chegar, tbell, smarks

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: e8a3edda1f60
Author:    lana
Date:      2013-08-20 17:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/e8a3edda1f60

Merge


Changeset: 056398db9dcb
Author:    lana
Date:      2013-08-23 14:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/056398db9dcb

Merge

! common/autoconf/generated-configure.sh

Changeset: f8405a0fa69c
Author:    erikj
Date:      2013-08-26 13:43 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/f8405a0fa69c

8023216: Feedback on README-builds.html
Reviewed-by: anthony, robilad, tbell

! README-builds.html

Changeset: 5166118c5917
Author:    katleman
Date:      2013-08-26 17:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/5166118c5917

Merge


Changeset: 246cdbaa6c62
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/rev/246cdbaa6c62

Added tag jdk8-b105 for changeset 5166118c5917

! .hgtags


From john.coomes at oracle.com  Thu Aug 29 13:30:51 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 20:30:51 +0000
Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b105 for changeset
	4e38de7c767e
Message-ID: <20130829203054.4D917623EC@hg.openjdk.java.net>

Changeset: 2e3a056c84a7
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/2e3a056c84a7

Added tag jdk8-b105 for changeset 4e38de7c767e

! .hgtags


From john.coomes at oracle.com  Thu Aug 29 13:31:33 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 20:31:33 +0000
Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b105 for changeset
	88390df7ed2c
Message-ID: <20130829203142.95FD7623EE@hg.openjdk.java.net>

Changeset: 01be6f93d0a4
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/01be6f93d0a4

Added tag jdk8-b105 for changeset 88390df7ed2c

! .hgtags


From john.coomes at oracle.com  Thu Aug 29 14:03:27 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 21:03:27 +0000
Subject: hg: hsx/hotspot-rt/langtools: 29 new changesets
Message-ID: <20130829210511.3FE4F623F1@hg.openjdk.java.net>

Changeset: b8610a65fbf9
Author:    vromero
Date:      2013-08-08 11:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b8610a65fbf9

8019486: javac, generates erroneous LVT for a test case with lambda code
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/T8019486/WrongLVTForLambdaTest.java

Changeset: d601238641e6
Author:    ksrini
Date:      2013-08-09 15:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d601238641e6

8022161: javac Null Pointer Exception in Enter.visitTopLevel
Reviewed-by: jjg, vromero, jlahoda

! src/share/classes/com/sun/tools/javac/comp/Enter.java
! test/tools/javac/TestPkgInfo.java

Changeset: 0d9bc764cac7
Author:    vromero
Date:      2013-08-10 13:27 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/0d9bc764cac7

8009640: -profile <compact> does not work when -bootclasspath specified
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java

Changeset: 8f282dc58dfc
Author:    vromero
Date:      2013-08-10 16:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8f282dc58dfc

8022622: javac, two tests are failing with compile time error after class Collector was modified
Reviewed-by: mcimadamore

! test/tools/javac/lambda/TargetType59.java
! test/tools/javac/lambda/TargetType62.java

Changeset: aa6c6f8b5622
Author:    vromero
Date:      2013-08-10 16:29 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/aa6c6f8b5622

6983297: methods missing from NewArrayTree
Reviewed-by: jjg

! src/share/classes/com/sun/source/tree/NewArrayTree.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! test/tools/javac/tree/SourceTreeScannerTest.java

Changeset: f7f271bd74a2
Author:    mcimadamore
Date:      2013-08-12 17:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f7f271bd74a2

6537020: JCK tests: a compile-time error should be given in case of ambiguously imported fields (types, methods)
Summary: Hiding check does not support interface multiple inheritance
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/4980495/static/Test.out
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java
+ test/tools/javac/staticImport/6537020/T6537020.java
+ test/tools/javac/staticImport/6537020/T6537020.out

Changeset: af80273f630a
Author:    mcimadamore
Date:      2013-08-12 17:28 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/af80273f630a

8021567: Javac doesn't report \"java: reference to method is ambiguous\" any more
Summary: Javac incorrectly forgets about constant folding results within lambdas
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/8021567/T8021567.java
+ test/tools/javac/lambda/8021567/T8021567.out
+ test/tools/javac/lambda/8021567/T8021567b.java

Changeset: 32b6a99cc74e
Author:    lana
Date:      2013-08-13 18:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/32b6a99cc74e

Merge


Changeset: 0ad781399706
Author:    vromero
Date:      2013-08-14 10:53 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/0ad781399706

8013394: compile of iterator use fails with error \"defined in an inaccessible class or interface\"
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T8013394/CompileErrorWithIteratorTest.java

Changeset: 3ab468194f11
Author:    ksrini
Date:      2013-08-14 07:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3ab468194f11

8007517: DefaultMethodRegressionTests.java fail in TL
Reviewed-by: jjg, vromero

- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java

Changeset: 14faef2b51eb
Author:    jjg
Date:      2013-08-14 16:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/14faef2b51eb

8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
+ test/com/sun/javadoc/testSeeTag/TestSeeTag.java
+ test/com/sun/javadoc/testSeeTag/pkg/Test.java

Changeset: fac0d1bb87f2
Author:    ksrini
Date:      2013-08-14 18:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/fac0d1bb87f2

6840442: JavaCompiler.getTask() has incomplete specification for IllegalArgumentException
Reviewed-by: jjg

! src/share/classes/javax/tools/JavaCompiler.java

Changeset: 3d4f0fa2ad05
Author:    bpatel
Date:      2013-08-14 21:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3d4f0fa2ad05

8016921: Change the profiles table on overview-summary.html page to a list
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java

Changeset: 71b0089b146f
Author:    erikj
Date:      2013-08-15 17:24 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/71b0089b146f

8015145: Smartjavac needs more flexibility with linking to sources
Reviewed-by: jjg, ohrstrom

! src/share/classes/com/sun/tools/sjavac/JavacState.java
! src/share/classes/com/sun/tools/sjavac/Main.java
! test/tools/sjavac/SJavac.java

Changeset: a6378c19836b
Author:    vromero
Date:      2013-08-16 10:32 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a6378c19836b

8022053: javac generates unverifiable initializer for nested subclass of local class
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T8022053/UnverifiableInitForNestedLocalClassTest.java

Changeset: ec77c7b46c37
Author:    jlahoda
Date:      2013-08-15 22:33 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ec77c7b46c37

8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression
Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java
+ test/tools/javac/lambda/ExceptionsInLambda.java
+ test/tools/javac/lambda/ExceptionsInLambda.out
! test/tools/javac/lambda/TargetType21.out

Changeset: f657d400c736
Author:    jlahoda
Date:      2013-08-15 22:36 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f657d400c736

8022508: javac crashes if the generics arity of a base class is wrong
Reviewed-by: mcimadamore, vromero

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/generics/8016640/T8016640.java

Changeset: 4300c2f5fb1b
Author:    erikj
Date:      2013-08-16 16:00 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4300c2f5fb1b

8023146: Sjavac test failes in langtools nightly
Reviewed-by: mcimadamore, jfranck

! test/tools/sjavac/SJavac.java

Changeset: 389eaf6ed973
Author:    ksrini
Date:      2013-08-19 07:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/389eaf6ed973

7071377: Exception when javac -processor is given a class name with invalid postfix
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/processing/errors/TestClassNames.java

Changeset: 55da6b3a6940
Author:    kizune
Date:      2013-08-20 17:34 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/55da6b3a6940

7182350: Regression in wording of unchecked warning message
Reviewed-by: mcimadamore, jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/6758789/T6758789b.out
+ test/tools/javac/7182350/T7182350.java
+ test/tools/javac/7182350/T7182350.out
! test/tools/javac/generics/7015430/T7015430_1.out
! test/tools/javac/generics/7015430/T7015430_2.out
! test/tools/javac/generics/7151802/T7151802.out
! test/tools/javac/generics/inference/6718364/T6718364.out
! test/tools/javac/generics/inference/7177306/T7177306a.out

Changeset: e811fb09a1dc
Author:    jfranck
Date:      2013-08-20 17:21 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/e811fb09a1dc

8019243: AnnotationTypeMismatchException instead of MirroredTypeException
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
+ test/tools/javac/processing/errors/EnsureMirroredTypeException/Processor.java
+ test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.java
+ test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.out

Changeset: 58da1296c6b3
Author:    darcy
Date:      2013-08-20 12:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/58da1296c6b3

8011043: Warn about use of 1.5 and earlier source and target values
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javadoc/Start.java
+ test/tools/javac/diags/examples/ObsoleteSourceAndTarget.java

Changeset: 0f88e3d3d250
Author:    ksrini
Date:      2013-08-20 14:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/0f88e3d3d250

7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against JDK 7 and JDK 8
Reviewed-by: jjg

! test/tools/javac/processing/model/testgetallmembers/Main.java

Changeset: a76dc1b4c299
Author:    jjg
Date:      2013-08-20 14:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a76dc1b4c299

8020663: Restructure some properties to facilitate better translation
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java

Changeset: 79e341614c50
Author:    jjg
Date:      2013-08-20 14:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/79e341614c50

8022080: javadoc generates invalid HTML in Turkish locale
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java
! src/share/classes/com/sun/tools/doclint/HtmlTag.java

Changeset: 720992953d43
Author:    jjg
Date:      2013-08-20 15:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/720992953d43

8013887: In class use, some tables are randomly unsorted
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java

Changeset: b59a0b4675c9
Author:    lana
Date:      2013-08-20 17:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b59a0b4675c9

Merge

- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java

Changeset: 375834b5cf08
Author:    lana
Date:      2013-08-23 14:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/375834b5cf08

Merge

- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java

Changeset: e431c9bfb171
Author:    cl
Date:      2013-08-29 09:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/e431c9bfb171

Added tag jdk8-b105 for changeset 375834b5cf08

! .hgtags


From john.coomes at oracle.com  Thu Aug 29 14:05:31 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 21:05:31 +0000
Subject: hg: hsx/hotspot-rt/nashorn: 23 new changesets
Message-ID: <20130829210553.44FEF623F2@hg.openjdk.java.net>

Changeset: 9a3e3bb30db3
Author:    attila
Date:      2013-08-07 16:38 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/9a3e3bb30db3

8022509: Various Dynalink security enhancements
Reviewed-by: jlaskey, hannesw

! src/jdk/internal/dynalink/ChainedCallSite.java
! src/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk/internal/dynalink/beans/ClassString.java
! src/jdk/internal/dynalink/beans/StaticClassLinker.java
- src/jdk/internal/dynalink/support/Backport.java
! src/jdk/internal/dynalink/support/ClassMap.java
! src/jdk/internal/dynalink/support/Guards.java
! src/jdk/internal/dynalink/support/Lookup.java
! src/jdk/internal/dynalink/support/TypeConverterFactory.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java

Changeset: dd79c04ef7df
Author:    sundar
Date:      2013-08-08 16:38 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/dd79c04ef7df

8022524: Memory leaks in nashorn sources and tests found by jhat analysis
Reviewed-by: attila, hannesw

! make/project.properties
! src/jdk/nashorn/internal/codegen/CompileUnit.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeDate.java
! src/jdk/nashorn/internal/objects/NativeJSON.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/GlobalObject.java
! src/jdk/nashorn/internal/runtime/JSONFunctions.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! test/script/basic/JDK-8020357.js
! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java
! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java
! test/src/jdk/nashorn/internal/codegen/CompilerTest.java
! test/src/jdk/nashorn/internal/parser/ParserTest.java

Changeset: 0d7484bf8597
Author:    sundar
Date:      2013-08-08 18:19 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/0d7484bf8597

Merge

- src/jdk/internal/dynalink/support/Backport.java

Changeset: 14ea21d58f83
Author:    jlaskey
Date:      2013-08-08 11:20 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/14ea21d58f83

Merge

- src/jdk/internal/dynalink/support/Backport.java

Changeset: 47e2b609fe31
Author:    sundar
Date:      2013-08-09 20:48 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/47e2b609fe31

8022707: Revisit all doPrivileged blocks
Reviewed-by: jlaskey, hannesw

! make/project.properties
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeDebug.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ECMAErrors.java
! src/jdk/nashorn/internal/runtime/Logging.java
! src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java
! src/jdk/nashorn/internal/runtime/options/Options.java
! src/jdk/nashorn/tools/Shell.java

Changeset: 01304b0550fb
Author:    sundar
Date:      2013-08-12 14:43 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/01304b0550fb

8022782: publicLookup access failures in ScriptObject, ScriptFunction and ScriptFunction
Reviewed-by: lagergren, attila, hannesw

! src/jdk/nashorn/internal/codegen/CompilerConstants.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java

Changeset: 3c13fba4d727
Author:    attila
Date:      2013-08-12 12:46 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/3c13fba4d727

8022789: Revisit doPrivileged blocks in Dynalink
Reviewed-by: lagergren, sundar

! src/jdk/internal/dynalink/DynamicLinkerFactory.java
+ src/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java
! src/jdk/internal/dynalink/support/ClassMap.java
! src/jdk/internal/dynalink/support/TypeConverterFactory.java

Changeset: 0bbaa0ac36ab
Author:    sundar
Date:      2013-08-12 16:52 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/0bbaa0ac36ab

8022614: Please exclude test test/script/trusted/JDK-8020809.js from Nashorn code coverage run
Reviewed-by: jlaskey, lagergren

! exclude/exclude_list_cc.txt

Changeset: 03ba1cd734c0
Author:    hannesw
Date:      2013-08-12 13:31 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/03ba1cd734c0

8022731: NativeArguments has wrong implementation of isMapped()
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeArguments.java
+ test/script/basic/JDK-8022731.js
+ test/script/basic/JDK-8022731.js.EXPECTED

Changeset: 821b605c7046
Author:    sundar
Date:      2013-08-12 17:08 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/821b605c7046

8022615: [nightly] Two nashorn print tests fail in nightly builds on Windows
Reviewed-by: lagergren, jlaskey

! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: f2e1673db03b
Author:    sundar
Date:      2013-08-12 18:16 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f2e1673db03b

8022598: Object.getPrototypeOf should return null for host objects rather than throwing TypeError
Reviewed-by: lagergren, jlaskey, attila, hannesw

! src/jdk/nashorn/internal/objects/NativeObject.java
+ test/script/basic/JDK-8022598.js

Changeset: a0807e889be3
Author:    sundar
Date:      2013-08-12 20:37 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/a0807e889be3

Merge


Changeset: 8ecf68b292d0
Author:    lana
Date:      2013-08-13 18:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/8ecf68b292d0

Merge


Changeset: bbc4e9d37315
Author:    jlaskey
Date:      2013-08-12 18:00 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/bbc4e9d37315

8022676: Confusing error message checking instanceof non-class
Reviewed-by: jlaskey, sundar
Contributed-by: michael.horowitz at oracle.com

! src/jdk/nashorn/internal/runtime/resources/Messages.properties

Changeset: ba507ac08719
Author:    sundar
Date:      2013-08-14 20:51 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/ba507ac08719

8023026: Array.prototype iterator functions like forEach, reduce should work for Java arrays, lists
Reviewed-by: jlaskey, lagergren

- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/JavaListIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseJavaListIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseScriptArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ScriptArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ScriptObjectIterator.java
+ test/script/basic/JDK-8023026.js
+ test/script/basic/JDK-8023026.js.EXPECTED

Changeset: 09c99b58b81e
Author:    sundar
Date:      2013-08-16 15:04 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/09c99b58b81e

8020355: bind on built-in constructors don't use bound argument values
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
+ test/script/basic/JDK-8020355.js

Changeset: 1d29d2e27590
Author:    hannesw
Date:      2013-08-16 13:42 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/1d29d2e27590

8019985: Date.parse("2000-01-01T00:00:00.Z") should return NaN
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/parser/DateParser.java
+ test/script/basic/JDK-8019985.js

Changeset: 36fb36217e1d
Author:    lagergren
Date:      2013-08-16 18:51 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/36fb36217e1d

8023017: SUB missing for widest op == number for BinaryNode
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java
! src/jdk/nashorn/internal/codegen/ObjectCreator.java
! src/jdk/nashorn/internal/ir/BinaryNode.java
! src/jdk/nashorn/internal/ir/BreakableNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/LexicalContextNode.java
! src/jdk/nashorn/internal/objects/NativeArguments.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java
! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethod.java
! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java

Changeset: bd0174b1a42f
Author:    sundar
Date:      2013-08-19 17:16 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/bd0174b1a42f

8023210: jjs tools should support a mode where it will load few command line scripts and then entering into interactive shell
Reviewed-by: hannesw, attila, lagergren, jlaskey

! src/jdk/nashorn/internal/runtime/options/Options.java
! src/jdk/nashorn/tools/Shell.java

Changeset: e628aefac504
Author:    sundar
Date:      2013-08-19 19:37 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/e628aefac504

Merge

- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: 1f2394beecf7
Author:    lana
Date:      2013-08-20 17:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/1f2394beecf7

Merge

- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: f484bfb624dd
Author:    lana
Date:      2013-08-23 14:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f484bfb624dd

Merge

- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: 824d33e678f2
Author:    cl
Date:      2013-08-29 09:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/824d33e678f2

Added tag jdk8-b105 for changeset f484bfb624dd

! .hgtags


From yumin.qi at oracle.com  Thu Aug 29 14:37:39 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 29 Aug 2013 14:37:39 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521F9503.3010108@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
	<52177780.3040109@oracle.com> <5217E333.9020802@oracle.com>
	<5217EAC4.9090001@oracle.com> <521B4041.5050300@oracle.com>
	<521B89F4.6010403@oracle.com> <521C5CC8.5060102@oracle.com>
	<521CDE52.2030407@oracle.com> <521D6F68.6050000@oracle.com>
	<521F9503.3010108@oracle.com>
Message-ID: <521FBF23.40203@oracle.com>

Hi, loise

   Thanks for your review. I will send out a new webrev soon.
   For your concern, see embedded answers.

> arguments.cpp - looks good, no comments
I will add another functions, is_filename_valid, and in this functions, 
check if the given filename is 'legal' function name, currently we did 
not check for this.
>
> ostream.hpp - looks good, no comments
>
> ostream.cpp -
>
>     - Have you tried a file name that is 255 characters?  It would 
> seem that after you appended the pid + timestamp + .current + # you 
> could overrun this buffer?
>
>     439 #define FILENAMEBUFLEN 256
>         and subsequent use at
>     466 char tempbuf[FILENAMEBUFLEN];
>         467 jio_snprintf(tempbuf, sizeof(tempbuf), "%s.%d"
>     CURRENTAPPX, _file_name, _cur_file_num);
>
>     - I would also like to point out in line #467, there may not be a 
> need for "sizeof(tempbuf)", isn't it just FILENAMEBUFLEN?
>       Please check the use of "sizeof()" in the jio_sprintf 
> statements, I think all are known.
The FILENAMEBUFLEN will change to 1024 which is suffice for most of use 
cases.
for using sizeof(name of char[]), this way can save time for case that  
FILENAMEBUFLEN changed. Certainly, usually we don't change that.
>
>    - Related to my first comment.  If you have a time_msg that is 
> FILENAMEBUFLEN and you try to concatenate it with a file_name that is 
> FILENAMEBUFLEN + the
>      os::local_time_string, you've overrun your buffer.
>
>     493 char time_msg[FILENAMEBUFLEN];
>          494 char time_str[EXTRACHARLEN];
>          495 char current_file_name[FILENAMEBUFLEN];
>     496 char renamed_file_name[FILENAMEBUFLEN];
>          ...
>          530 jio_snprintf(time_msg, sizeof(time_msg), "%s GC log file
>     has reached the"
>          531                                         " maximum size.
>     Saved as %s\n",
>          532 os::local_time_string((char *)time_str, sizeof(time_str)),
>          533 renamed_file_name);
>
As above mentioned, now the buffer size is 1024 bytes.
>
>     - Line #538 dealing with the rename of <file_name>.current.#.  I 
> don't prefer the use of .current. Take for example a user
>       specified on the command line -XX:NumberOfGCLogFiles=5, but 
> there is enough -Xloggc info generated to fit in 7 files.  This
>       situation will cause the log file rotation to rotate back on 
> itself.  So, file #0 will be reopened and used as the 6th file, and
>       then the rotation will progress and finish dumping Xloggc 
> information into the last file which would be <file_name>.current.1,
>       correct?  So a user would be left with the following files.
>
>                         file_name.0 (which now has a later timestamp 
> in its name than file # 1 thru 4)
>                         file_name.1
>                         file_name.2
>                         file_name.3
>                         file_name.4
>                         file_name.current.1
>
>       I find this confusing, would you consider having the -Xloggc 
> information be dumped into the current #'ed file directly?
>
The current design is like this:
If rotate in same file, that is the file given by -Xloggc:<filename>, 
the file name will be extended according to '%p" and '%t'.
If rotate in multiple files, user need to quickly identify which one is 
the current file, so this is why I append .current to the file name.
For example, if -XX:NumberOfGCLogFiles=5,  it will be like:
file_name.0
file_name.1.current
file_name.2
file_name.3
file_name.4

The oldest file is file_name.1 which is erased when new file 
file_name.1.current created. The current logging file is the one with 
.current appended so it is easily to tell. If without this appendix, 
user only sees bunch of log files and not easy to spot which one is current.

>     - Line 587 FLAG_SET_DEFAULT(UseGCLogFileRotation, false);
>       I like that you implemented the idea to turn off GC log file 
> rotation and continue with the current file if you can't open the next 
> file, thank you.
>
That turned rotation off --- if the current file can grow, it will grow, 
just like no rotation case; if it can not grow, VM may or may not 
continue which depends on what happens.

Thanks
Yumin
> Thank you,
> Lois
>
> On 8/27/2013 11:32 PM, Yumin Qi wrote:
>> Hi,
>>
>>  Based on the discussion, I updated the webrev, and in this version
>> 1) deleted unused rotatingFileStream  constructor, which keep code 
>> shorter.
>> 2) removed reformat_filename in previous version.
>> 3) still keep original design, that if no rotation, just use file 
>> name given by -Xloggc:<filename>.
>>
>> Others are basically same.
>>
>> Please take a look and comment.
>>
>> http://cr.openjdk.java.net/~minqi/7164841/webrev02 
>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev02>
>>
>> Thanks
>> Yumin
>>
>> On 8/27/2013 10:13 AM, Tao Mao wrote:
>>>
>>>
>>> On 8/27/13 1:01 AM, Bengt Rutisson wrote:
>>>>
>>>> Yumin,
>>>>
>>>> On 8/26/13 7:01 PM, Yumin Qi wrote:
>>>>> Bengt,
>>>>>
>>>>>   Thanks for your comments.
>>>>>   Yes, as you said, the purpose of rotating logs is primarily 
>>>>> targeted for saving disk space. This bug is supplying customers 
>>>>> another option to prevent the previous gc logs from removed by 
>>>>> restart app without making copy. Now with this pid and time stamp 
>>>>> included in file name, we have more options for users. It is up to 
>>>>> user to make decision to or not to keep the logs. We cannot handle 
>>>>> all the requests in JVM, but we can offer the choices for users I 
>>>>> think. Any way, with either the previous rotating version, or the 
>>>>> one I am working, the logs will not grow constantly without limit 
>>>>> to blow storage out as long as users give enough attention.
>>>>>
>>>>>   My concern is for no log rotation, should we still use time 
>>>>> stamp in file name? I have one version for this, I hope get more 
>>>>> comments for that.
>>>>
>>>> Sorry if I wasn't clear before. I am not worried about the case 
>>>> when log rotation is turned on. What I was worried about was the 
>>>> case where a user is not using log rotation but is still piping the 
>>>> GC output to a file. That file will be overwritten every time the 
>>>> VM is restarted. If we add time stamps to the file name for this 
>>>> case then the file will not be overwritten. I think that is a bit 
>>>> of a scary change. That's all.
>>>
>>> If you are worried about the case where a user is not using log 
>>> rotation but creating a new file for each restart, you should be 
>>> almost equivalently worried about the case where a user is using log 
>>> rotation and having many rotated logs created which are different 
>>> for each VM restart. Basically, we are creating even more files over 
>>> time, which falls into your concern.
>>>
>>> At this point, I'm fine with either choice for they have pros and 
>>> cons. If we always append date and time to log file names, customers 
>>> may say "the logs are 'eating' my disk"; if you don't do that, the 
>>> customers would still complain the log is overwritten after a 
>>> restart (I saw these kinds of CR's twice).
>>>
>>> Thanks.
>>> Tao
>>>
>>>>
>>>> Bengt
>>>>
>>>>>
>>>>>   More comments are appreciated by sending to more wide audience, 
>>>>> especially sustaining, they have more experience with customer 
>>>>> request.
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>>
>>>>>
>>>>> On 8/26/2013 4:47 AM, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi Yumin and Tao,
>>>>>>
>>>>>> I have not reviewed the code change but I have a comment inlined 
>>>>>> below.
>>>>>>
>>>>>> On 8/24/13 1:05 AM, Yumin Qi wrote:
>>>>>>> Tao,
>>>>>>>
>>>>>>>   Thanks for your review.
>>>>>>>
>>>>>>> On 8/23/2013 3:33 PM, Tao Mao wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I reviewed most of the code and test-ran a build from it. It's 
>>>>>>>> a very cool and important improvement.
>>>>>>>>
>>>>>>>> Thank you for putting together these on our wishlist for long.
>>>>>>>>
>>>>>>>> Below are some comments.
>>>>>>>>
>>>>>>>> 1. src/share/vm/runtime/arguments.cpp
>>>>>>>>
>>>>>>>> - 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>>>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>>>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M]\n"
>>>>>>>> + 1853 "To enable GC log rotation, use -Xloggc:<filename> 
>>>>>>>> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> 
>>>>>>>> -XX:GCLogFileSize=<num_of_size>[k|K|m|M|g|G]\n"
>>>>>>>>
>>>>>>>> Please consider adding [g|G] to GCLogFileSize suggestion.
>>>>>>>>
>>>>>>>> I worked on a problem of enabling gc log limit over 2G 
>>>>>>>> (JDK-7122222). So it seems that customers sometimes want gc 
>>>>>>>> logs to be very large.
>>>>>>>>
>>>>>>> Sure, will add.
>>>>>>>> 2. src/share/vm/runtime/arguments.hpp
>>>>>>>>
>>>>>>>> (1) with the current changeset, we only append date&time to 
>>>>>>>> file_name w/ +UseGCLogFileRotation; if not, we won't have 
>>>>>>>> date&time info.
>>>>>>>>
>>>>>>>> I think it would be useful to let both cases (w/ and w/o 
>>>>>>>> UseGCLogFileRotation) have date&time in order to solve the 
>>>>>>>> overwritten problem (e.g. JDK-8020667). In fact, having that, 
>>>>>>>> we actually solve JDK-8020667.
>>>>>>>>
>>>>>>>> If you want to have that, basically you need to work on the 
>>>>>>>> FileStream constructor methods fileStream().
>>>>>>>>
>>>>>>> I can change that, if no objection from others. This also will 
>>>>>>> simplify the setting of file name here.
>>>>>>
>>>>>> I think appending a timestamp to the log file name is a nice 
>>>>>> idea, but I think it is also a bit scary. There are users who 
>>>>>> restart their applications regularly. With the suggested idea 
>>>>>> such users will now risk filling up their disk space with log 
>>>>>> files. I imagine that that will not be appreciated by everyone. 
>>>>>> Such a change should probably be discussed more thoroughly than 
>>>>>> just in a review request.
>>>>>>
>>>>>> Thanks,
>>>>>> Bengt
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> (2) Would it be better to rename method name 
>>>>>>>> reformat_filename() to extend_filename()?
>>>>>>>>
>>>>>>>> (3) Typos and suggestion
>>>>>>>> 537 // rotate file in names filename.0, filename.1, ..., 
>>>>>>>> filename.<NumberOfGCLogFiles - 1>
>>>>>>>> *=> extended_filename.0*
>>>>>>>>
>>>>>>>> 538 // filename contains pid and time when the fist file 
>>>>>>>> created. The current filename is
>>>>>>>> *=> *the*first *file created.
>>>>>>>>
>>>>>>>> 539 // gc_log_file_name + pid<pid> + 
>>>>>>>> YYYY-MM-DD_HH-MM-SS.<i>.current, where i is current
>>>>>>>> 540 // rotation file number. After it reaches max file size, 
>>>>>>>> the file will be saved and
>>>>>>>> 541 // renamed with .current removed from its tail.
>>>>>>>>
>>>>>>> Will change that.
>>>>>>>> 3. For your point 5), I don't quite get it. In my test-run, I 
>>>>>>>> tried to change file permission to unreadable and unwritable, 
>>>>>>>> but VM would later change the permission back anyway.
>>>>>>>>
>>>>>>>> So could you bring up some use cases of that functionality to 
>>>>>>>> give more details?
>>>>>>>>
>>>>>>> Changing file permission will not stop the file create, in this 
>>>>>>> rotation, the file opened/saved/removed/renamed -> then repeat. 
>>>>>>> What I have done is change the while directory to read only, 
>>>>>>> then the create failed so rotation stopped.
>>>>>>>
>>>>>>>> 4. Will you write jtreg tests for this functionality? It looks 
>>>>>>>> possible to write some tests, at least checking the format of 
>>>>>>>> log names.
>>>>>>>>
>>>>>>> Good suggestion, I will add one.
>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Tao
>>>>>>>>
>>>>>>>> On 8/23/13 7:53 AM, Yumin Qi wrote:
>>>>>>>>> Could I get  a GC staff review the change? Need more reviewers 
>>>>>>>>> to push this in.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 8/21/2013 3:43 PM, Yumin Qi wrote:
>>>>>>>>>> Hi, all
>>>>>>>>>>
>>>>>>>>>>   This is second version after feedback from first round.
>>>>>>>>>>   The changes are:
>>>>>>>>>>
>>>>>>>>>>   1) file name will be based on gc log file name 
>>>>>>>>>> (-Xloggc:filename), pid (process id) and time when the first 
>>>>>>>>>> rotation file created:
>>>>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>>>>>>>>>>   2) If rotate in same file, file name is as in 1), if rotate 
>>>>>>>>>> in multiple files, .<i> will append to above file name.
>>>>>>>>>>   3) every time file rotated, file name and time when file 
>>>>>>>>>> created will be logged to head/tail, this is same as first 
>>>>>>>>>> version.
>>>>>>>>>>   4) current file has name 
>>>>>>>>>> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>>>>>>>>>>        This is similar to first version.
>>>>>>>>>>        By adapting such name format we will never loss logs 
>>>>>>>>>> in case apps stops and restart, the log files will not be 
>>>>>>>>>> overwritten since time stamp in file names.
>>>>>>>>>>    5) If open file failed, turn off gc log rotation.
>>>>>>>>>>         If due to some reason, file operation failed (such as 
>>>>>>>>>> permission changed etc), with log file opened, logging still 
>>>>>>>>>> works, but at
>>>>>>>>>>         saving and renaming, the file operation will fail, 
>>>>>>>>>> this will lead not all files saved.
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>>>>>>>>>>
>>>>>>>>>>      Tested with jtreg, JPRT.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>   Can I have your review for this small changes?
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>>>>>>>>>>
>>>>>>>>>>>    This is for a enhancement to add head/tail message to the 
>>>>>>>>>>> logging files to assist reading GC output.
>>>>>>>>>>>    1. modified prompt message if invalid arguments used for 
>>>>>>>>>>> log rotating;
>>>>>>>>>>>    2. add time and file name message to log file head/tail.
>>>>>>>>>>>    3. for easily identify which log file is current, use 
>>>>>>>>>>> file name like <filename>.n.current, after it reaches 
>>>>>>>>>>> maximum size, rename it to <filename>.n
>>>>>>>>>>>         On Windows, there is no F_OK (existing test) 
>>>>>>>>>>> definition, F_OK is defined as "0" and for _access of VC++, 
>>>>>>>>>>> it just describes:
>>>>>>>>>>>
>>>>>>>>>>> modevalue
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Checks file for
>>>>>>>>>>>
>>>>>>>>>>> 00
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Existence only
>>>>>>>>>>>
>>>>>>>>>>> 02
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Write-only
>>>>>>>>>>>
>>>>>>>>>>> 04
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Read-only
>>>>>>>>>>>
>>>>>>>>>>> 06
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Read and write
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>>>>>>>>>>> The definition are consistent with unistd.h.
>>>>>>>>>>>
>>>>>>>>>>>     Test: JPRT and jtreg.
>>>>>>>>>>>
>>>>>>>>>>>    Thanks
>>>>>>>>>>>    Yumin
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/30187ff6/attachment-0001.html 

From vladimir.kozlov at oracle.com  Thu Aug 29 14:47:22 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 29 Aug 2013 14:47:22 -0700
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521FA227.3000305@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521F97EE.9060407@oracle.com> <521F9EE2.2000403@oracle.com>
	<521FA227.3000305@oracle.com>
Message-ID: <521FC16A.6040601@oracle.com>

Lois,

Never mind my previous comment. I missed that you added throw() to all 
new() operators. The problem with ppc64 port was the missed throw() in 
new() operator declaration in header file. And you fixed it. So I think 
your changes are fine.

I assume it passed JPRT (and all embedded) builds.

thanks,
Vladimir

On 8/29/13 12:33 PM, Vladimir Kozlov wrote:
> Lois,
>
> On 8/29/13 12:20 PM, Calvin Cheung wrote:
>> Hi Lois,
>>
>> src/share/vm/code/nmethod.cpp
>>
>> 803 void* nmethod::operator new(size_t size, int nmethod_size) throw() {
>
> Could you remove this throw()? As David pointed it was discussed and, we
> think, it was added by mistake.
>
> thanks,
> Vladimir
>
>>
>> The above line looks the same to me after the change.
>> So perhaps the file doesn't need to be changed (other than the copyright
>> year)?
>>
>> Calvin
>>
>> On 8/29/2013 11:50 AM, Coleen Phillimore wrote:
>>>
>>> Lois,
>>>
>>> This does looks better than the NOEXCEPT macros.  Can other people
>>> review this today?  We need this for the clang c++ compiler upgrade
>>> testing.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 08/29/2013 02:33 PM, Lois Foltan wrote:
>>>>
>>>> Please review the following updated webrev:
>>>>
>>>> Internal webrev:
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>>>>
>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file
>>>> produced &
>>>>          runtime/6878713/Test6878713.sh fails on mac
>>>>
>>>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>
>>>> Summary of fix:
>>>>     On MacOS, currently Hotspot is built specifying the -fcheck-new
>>>> command line option to the llvm-g++ compiler.
>>>>     The -fcheck-new option directs the compiler to "check that the
>>>> pointer returned by |operator new| is non-null
>>>>      before attempting to modify the storage allocated."  The clang++
>>>> compiler does not support the
>>>>      -fcheck-new option.  To obtain similiar functionality when
>>>> building Hotspot with clang++, empty exception
>>>>      throw() specifications must be added to all user-defined
>>>> operator new()'s.
>>>>
>>>> Tests:
>>>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010,
>>>> MacOS (llvm-g++ & clang++)
>>>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>>>
>>>> Original Testing:
>>>>      Solaris: built fastdebug & product images
>>>>      Linux: built fastdebug & product images
>>>>      MacOS:  built fastdebug & product images using llvm-g++ - ran
>>>> JTREG
>>>>                     built fastdebug & product images using clang++ -
>>>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>>>      Windows:  built fastdebug & product images with VS2010
>>>>
>>>> Thank you,
>>>> Lois
>>>>
>>>
>>

From john.coomes at oracle.com  Thu Aug 29 13:34:34 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 29 Aug 2013 20:34:34 +0000
Subject: hg: hsx/hotspot-rt/jdk: 98 new changesets
Message-ID: <20130829205955.1C696623EF@hg.openjdk.java.net>

Changeset: 2722f4000b65
Author:    jgodinez
Date:      2013-08-15 11:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2722f4000b65

8023045: [MacOSX] PrinterIOException when printing a JComponent
Reviewed-by: bae, jchen

! src/share/classes/sun/print/PSPrinterJob.java

Changeset: b44ce67c0565
Author:    vadim
Date:      2013-08-16 15:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b44ce67c0565

8013446: [parfait] Memory leak in jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
Reviewed-by: bae, prr

! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c

Changeset: dadd43e02a79
Author:    prr
Date:      2013-08-19 03:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dadd43e02a79

8017580: Crash in font loading code on Linux (due to use of reflection)
Reviewed-by: bae, vadim

! src/share/native/sun/font/sunFont.c
! src/share/native/sun/font/sunfontids.h

Changeset: 0c950b2be7ab
Author:    jgodinez
Date:      2013-08-19 11:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0c950b2be7ab

8022241: [macosx] [PIT] lookupPrintServices() returns one too long array
Reviewed-by: prr, jchen

! src/solaris/classes/sun/print/UnixPrintServiceLookup.java

Changeset: 64be71ae6185
Author:    lana
Date:      2013-08-20 17:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/64be71ae6185

Merge


Changeset: 903a279f1fce
Author:    ant
Date:      2013-08-09 05:20 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/903a279f1fce

8013611: Modal dialog fails to obtain keyboard focus
Reviewed-by: leonidr

! src/share/classes/java/awt/KeyboardFocusManager.java
+ test/java/awt/Focus/8013611/JDK8013611.java

Changeset: 2cd1a041381b
Author:    alexsch
Date:      2013-08-09 14:16 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2cd1a041381b

7121409: Two conformance tests for AccessibleText.getCharacterBounds(int i) fail
Reviewed-by: serb

! src/share/classes/javax/swing/JLabel.java

Changeset: 4702ab74b70a
Author:    serb
Date:      2013-08-13 15:41 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4702ab74b70a

7027045: (doc) java/awt/Window.java has several typos in javadoc
Reviewed-by: art, serb
Contributed-by: konstantin.perikov at gmail.com

! src/share/classes/java/awt/Window.java

Changeset: 149bf2400fa1
Author:    lana
Date:      2013-08-13 15:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/149bf2400fa1

Merge

- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: c5db3ec83cba
Author:    pchelko
Date:      2013-08-14 16:17 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c5db3ec83cba

8013454: [parfait] Memory leak in jdk/src/windows/native/sun/windows/awt_Cursor.cpp
8012079: [parfait] possible null pointer dereference in jdk/src/windows/native/sun/windows/awt_Font.cpp
Reviewed-by: art, serb

! src/windows/native/sun/windows/awt_Cursor.cpp
! src/windows/native/sun/windows/awt_Font.cpp

Changeset: 1d6ce0070fd3
Author:    pchelko
Date:      2013-08-14 17:20 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1d6ce0070fd3

7173464: Clipboard.getAvailableDataFlavors: Comparison method violates contract
Reviewed-by: anthony, art, serb

! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
+ test/sun/awt/datatransfer/DataFlavorComparatorTest.java

Changeset: 3930a827160a
Author:    leonidr
Date:      2013-08-15 01:17 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3930a827160a

8022997: [macosx] Remaining duplicated key events
Reviewed-by: anthony, serb

! src/macosx/native/sun/awt/CMenuItem.m
! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java

Changeset: d7a34d7e7f22
Author:    alitvinov
Date:      2013-08-15 14:20 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d7a34d7e7f22

7191018: Manual test closed/java/awt/JAWT causes JVM to crash starting from JDK 5
Reviewed-by: anthony, serb

! src/solaris/native/sun/awt/awt_DrawingSurface.c

Changeset: c089e93e6444
Author:    serb
Date:      2013-08-16 16:52 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c089e93e6444

8020051: [TEST_BUG] Testcase for 8004859 has a typo
Reviewed-by: anthony

! test/java/awt/Graphics2D/Test8004859/Test8004859.java

Changeset: e3316cd6ca47
Author:    serb
Date:      2013-08-16 20:56 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e3316cd6ca47

8006085: [findbugs] a warning on javax.sound.sampled.DataLine$Info constructor
Reviewed-by: art, prr

! src/share/classes/javax/sound/sampled/DataLine.java

Changeset: 64dc24e0d577
Author:    serb
Date:      2013-08-16 21:18 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/64dc24e0d577

8005980: [findbugs] More com.sun.media.sound.* warnings
Reviewed-by: art, prr

! src/share/classes/com/sun/media/sound/DataPusher.java
! src/share/classes/com/sun/media/sound/ModelStandardDirector.java
! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftMixingClip.java
! src/share/classes/sun/audio/AudioData.java

Changeset: fefa29e15a14
Author:    lana
Date:      2013-08-20 17:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fefa29e15a14

Merge


Changeset: 0beaa65c90c8
Author:    okutsu
Date:      2013-08-08 13:51 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0beaa65c90c8

8015986: Incorrect Localization of HijrahChronology
Reviewed-by: naoto
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com

! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/CalendarType.java
! src/share/classes/sun/text/resources/FormatData.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java

Changeset: 2c4f1081a0fa
Author:    uta
Date:      2013-08-08 09:16 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2c4f1081a0fa

7147084: (process) appA hangs when read output stream of appB which starts appC that runs forever
Reviewed-by: alanb, robm, martin

! src/windows/classes/java/lang/ProcessImpl.java
! src/windows/native/java/lang/ProcessImpl_md.c
+ test/java/lang/ProcessBuilder/InheritIOEHandle.java
+ test/java/lang/ProcessBuilder/SiblingIOEHandle.java

Changeset: b7d594716f86
Author:    weijun
Date:      2013-08-08 21:13 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b7d594716f86

8016594: Native Windows ccache still reads DES tickets
Reviewed-by: dsamersoff, xuelei

! src/share/classes/sun/security/krb5/Credentials.java
! src/share/native/sun/security/krb5/nativeccache.c
! src/windows/native/sun/security/krb5/NativeCreds.c

Changeset: a388263a7287
Author:    sherman
Date:      2013-08-08 12:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a388263a7287

8015666: test/tools/pack200/TimeStamp.java failing
Summary: to keep the default behavior of ZOS unchanged, if ze extra time not explicitly set
Reviewed-by: alanb, ksrini

! src/share/classes/java/util/zip/ZipConstants.java
! src/share/classes/java/util/zip/ZipEntry.java
! src/share/classes/java/util/zip/ZipFile.java
! src/share/classes/java/util/zip/ZipInputStream.java
! src/share/classes/java/util/zip/ZipOutputStream.java
! src/share/classes/java/util/zip/ZipUtils.java
! test/ProblemList.txt
! test/java/util/zip/TestExtraTime.java
! test/tools/pack200/TimeStamp.java

Changeset: 67edbf7e6b26
Author:    juh
Date:      2013-08-08 17:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/67edbf7e6b26

8022461: Fix lint warnings in sun.security.{provider,rsa,x509}
Reviewed-by: darcy, weijun, xuelei, mullan

! src/share/classes/sun/security/provider/DSAPublicKey.java
! src/share/classes/sun/security/rsa/RSAPublicKeyImpl.java
! src/share/classes/sun/security/rsa/RSASignature.java
! src/share/classes/sun/security/x509/AlgIdDSA.java
! src/share/classes/sun/security/x509/X509Key.java

Changeset: 758e3117899c
Author:    weijun
Date:      2013-08-09 11:41 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/758e3117899c

8021788: JarInputStream doesn't provide certificates for some file under META-INF
Reviewed-by: chegar, sherman

! src/share/classes/java/util/jar/JarVerifier.java
+ test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java

Changeset: 54f0ccdd9ad7
Author:    sherman
Date:      2013-08-08 23:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/54f0ccdd9ad7

6614237: missing codepage Cp290 at java runtime
Summary: to add charset Cp290 and Cp300
Reviewed-by: okutsu

+ make/tools/CharsetMapping/IBM290.c2b
+ make/tools/CharsetMapping/IBM290.map
+ make/tools/CharsetMapping/IBM300.c2b
+ make/tools/CharsetMapping/IBM300.map
! make/tools/CharsetMapping/dbcs
! make/tools/CharsetMapping/extsbcs
! make/tools/src/build/tools/charsetmapping/DBCS.java
! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java

Changeset: c29ca19cb816
Author:    psandoz
Date:      2013-08-09 11:44 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c29ca19cb816

8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED
Reviewed-by: martin, chegar

! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java

Changeset: 84004d0e3fdd
Author:    chegar
Date:      2013-08-09 13:50 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/84004d0e3fdd

8022661: InetAddress.writeObject() performs flush() on object output stream
Reviewed-by: michaelm, alanb

! src/share/classes/java/net/InetAddress.java

Changeset: ce1c874903cb
Author:    dl
Date:      2013-08-09 17:56 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ce1c874903cb

8022724: lint warnings in j.u.concurrent packages
Reviewed-by: chegar, lancea, darcy

! src/share/classes/java/util/concurrent/CompletableFuture.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/atomic/Striped64.java

Changeset: 03822f2389bf
Author:    dxu
Date:      2013-08-09 10:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/03822f2389bf

8021977: Opening a file using java.io can throw IOException on Windows
Summary: Remove IOException related error-handling code for backward compatibility
Reviewed-by: alanb, lancea, mr

! src/windows/native/java/io/io_util_md.c

Changeset: a7c341f30747
Author:    sherman
Date:      2013-08-09 12:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a7c341f30747

8020054: (tz) Support tzdata2013d
Summary: update the jdk8 tz data to version 2013d
Reviewed-by: coffeys, peytoia

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/antarctica
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/etcetera
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/factory
! make/sun/javazic/tzdata/iso3166.tab
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/pacificnew
! make/sun/javazic/tzdata/solar87
! make/sun/javazic/tzdata/solar88
! make/sun/javazic/tzdata/solar89
! make/sun/javazic/tzdata/southamerica
! make/sun/javazic/tzdata/systemv
! make/sun/javazic/tzdata/zone.tab
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/antarctica
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/australasia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/etcetera
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/factory
! test/sun/util/calendar/zi/tzdata/iso3166.tab
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/pacificnew
! test/sun/util/calendar/zi/tzdata/solar87
! test/sun/util/calendar/zi/tzdata/solar88
! test/sun/util/calendar/zi/tzdata/solar89
! test/sun/util/calendar/zi/tzdata/southamerica
! test/sun/util/calendar/zi/tzdata/systemv
! test/sun/util/calendar/zi/tzdata/zone.tab

Changeset: 8f01ccb0c981
Author:    joehw
Date:      2013-08-09 12:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8f01ccb0c981

8022548: SPECJVM2008 has errors introduced in 7u40-b34
Reviewed-by: chegar, lancea

+ test/javax/xml/jaxp/parsers/8022548/JDK8022548.xml
+ test/javax/xml/jaxp/parsers/8022548/JDK8022548.xsl
+ test/javax/xml/jaxp/parsers/8022548/TestBase.java
+ test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java

Changeset: ea4f4164422e
Author:    xuelei
Date:      2013-08-11 18:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ea4f4164422e

8022487: DEREncodedKeyValue.supportedKeyTypes should be private
Reviewed-by: mullan

! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java

Changeset: ffacf3e7a130
Author:    mullan
Date:      2013-08-12 09:03 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ffacf3e7a130

8016848: javax_security/auth/login tests fail in compact 1 and 2 profiles
Summary: Change the default value of the "login.configuration.provider" security property to sun.security.provider.ConfigFile
Reviewed-by: xuelei

! src/share/classes/com/sun/security/auth/login/ConfigFile.java
! src/share/classes/javax/security/auth/login/Configuration.java
+ src/share/classes/sun/security/provider/ConfigFile.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
! src/share/classes/sun/security/provider/SunEntries.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: d73fbf005f5f
Author:    mullan
Date:      2013-08-12 09:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d73fbf005f5f

Merge

- src/share/classes/java/net/package.html
- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: 70c8f4a4b8d6
Author:    vromero
Date:      2013-08-12 17:40 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/70c8f4a4b8d6

8015780: java/lang/reflect/Method/GenericStringTest.java failing
Reviewed-by: darcy, jfranck

! test/ProblemList.txt
! test/java/lang/reflect/Method/GenericStringTest.java

Changeset: 7758bcf0ab6b
Author:    henryjen
Date:      2013-08-12 12:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7758bcf0ab6b

8022749: Convert junit tests to testng in test/java/lang/invoke
Reviewed-by: mduigou, alanb
Contributed-by: Mani Sarkar <sadhak001 at gmail.com>

! test/java/lang/invoke/AccessControlTest.java
! test/java/lang/invoke/ClassValueTest.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/lang/invoke/PermuteArgsTest.java
! test/java/lang/invoke/ThrowExceptionsTest.java

Changeset: cc64a05836a7
Author:    lancea
Date:      2013-08-12 16:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cc64a05836a7

8022753: SQLXML javadoc example typo
Reviewed-by: alanb, mchung

! src/share/classes/java/sql/SQLXML.java

Changeset: 5b14d702b0b8
Author:    ascarpino
Date:      2013-08-12 11:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5b14d702b0b8

8020081: Cipher with OAEPPadding and OAEPParameterSpec can't be created
Reviewed-by: mullan

! src/share/classes/com/sun/crypto/provider/SunJCE.java
+ test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java

Changeset: 818c3f82269c
Author:    vinnie
Date:      2013-08-13 14:15 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/818c3f82269c

8013170: Spec for PBEParameterSpec does not specify behavior when paramSpec is null
Reviewed-by: mullan

! src/share/classes/javax/crypto/spec/PBEParameterSpec.java

Changeset: 26753a05859a
Author:    vinnie
Date:      2013-08-13 14:18 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/26753a05859a

Merge


Changeset: 834faf2081b3
Author:    bpb
Date:      2013-08-12 16:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/834faf2081b3

8022180: BigInteger Burnikel-Ziegler quotient and remainder calculation assumes quotient parameter is zero
Summary: Clear the quotient in divideAndRemainderBurnikelZiegler() if the divisor is larger than the dividend.
Reviewed-by: alanb, bpb
Contributed-by: Timothy Buktu <tbuktu at hotmail.com>

! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java

Changeset: 18e15d92610b
Author:    chegar
Date:      2013-08-13 14:57 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/18e15d92610b

8022779: ProblemList.txt updates (8/2013)
Summary: Update ProblemList and remove AggressiveOpts MOAT test run
Reviewed-by: chegar, alanb
Contributed-by: Amy Lu <amy.lu at oracle.com>

! test/ProblemList.txt
! test/java/util/Collection/MOAT.java

Changeset: 78c102c3eefc
Author:    dfuchs
Date:      2013-08-13 16:00 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/78c102c3eefc

8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is failing intermittently
Reviewed-by: mchung, dholmes

! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java

Changeset: 412b2f0950a9
Author:    mullan
Date:      2013-08-13 10:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/412b2f0950a9

8022897: Add test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java to ProblemList
Reviewed-by: vinnie, chegar

! test/ProblemList.txt

Changeset: 19133b3af95f
Author:    mullan
Date:      2013-08-13 10:07 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/19133b3af95f

Merge

! test/ProblemList.txt

Changeset: cd9379e348d0
Author:    darcy
Date:      2013-08-13 10:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cd9379e348d0

8022959: Fix new doclint issues in java.util.zip
Reviewed-by: chegar

! src/share/classes/java/util/zip/ZipEntry.java

Changeset: a4b0be7341ef
Author:    robm
Date:      2013-08-13 19:10 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a4b0be7341ef

5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
Reviewed-by: alanb, dholmes, martin, erikj, coffeys

! make/java/java/Exportedfiles.gmk
! make/java/java/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
! src/solaris/classes/java/lang/UNIXProcess.java.solaris
! src/solaris/native/java/lang/UNIXProcess_md.c
+ src/solaris/native/java/lang/childproc.c
+ src/solaris/native/java/lang/childproc.h
+ src/solaris/native/java/lang/jspawnhelper.c
! test/java/lang/ProcessBuilder/Basic.java

Changeset: 18ce880b5fb4
Author:    lana
Date:      2013-08-13 18:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/18ce880b5fb4

Merge

! makefiles/CompileNativeLibraries.gmk

Changeset: cb74d71fd02f
Author:    hseigel
Date:      2013-08-13 10:56 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cb74d71fd02f

8022259: MakeClasslist is buggy and its README is out of date.
Summary: Fixed bug in FOR loop and updated comments and README
Reviewed-by: dholmes, alanb

! make/tools/sharing/README.txt
! make/tools/src/build/tools/makeclasslist/MakeClasslist.java

Changeset: f9cf6ecf596c
Author:    coleenp
Date:      2013-08-14 10:14 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f9cf6ecf596c

Merge


Changeset: bc3cafb17c09
Author:    ksrini
Date:      2013-08-14 08:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bc3cafb17c09

8022547: [verifier] move DefaultMethodRegressionTests.java to jdk
Reviewed-by: acorn

+ test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java
+ test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java

Changeset: 444a7edcf367
Author:    darcy
Date:      2013-08-14 11:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/444a7edcf367

8022990: Fix dep_ann lint warnings in swing code
Reviewed-by: alexsch

! src/share/classes/com/sun/java/swing/Painter.java
! src/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java
! src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java

Changeset: c138d1b608e0
Author:    sherman
Date:      2013-08-14 11:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c138d1b608e0

8022178: System.console() throws IOE on some Windows
Summary: to remove the IOE throwing code
Reviewed-by: alanb

! src/windows/native/java/io/Console_md.c

Changeset: 17dfbb3f60d3
Author:    bpb
Date:      2013-08-12 10:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/17dfbb3f60d3

8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math
Summary: Add the methods for parameter types int and long.
Reviewed-by: mduigou
Contributed-by: Brian Burkhalter <brian.burkhalter at oracle.com>

! src/share/classes/java/lang/Math.java
! test/java/lang/Math/ExactArithTests.java

Changeset: f8af3499c1fb
Author:    wetmore
Date:      2013-08-14 19:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f8af3499c1fb

8023075: JDK-5049299 has broken old make in jdk8
Reviewed-by: katleman

! make/java/java/Makefile

Changeset: 2f6523abab08
Author:    yhuang
Date:      2013-08-14 22:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2f6523abab08

8021121: ISO 4217 Amendment Number 156
Reviewed-by: naoto

! src/share/classes/java/util/CurrencyData.properties
! src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties
! test/java/util/Currency/tablea1.txt
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: 5ff3b55df2d4
Author:    alanb
Date:      2013-08-15 11:54 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5ff3b55df2d4

8022921: Remove experimental Profile attribute
Reviewed-by: mchung, chegar

! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/util/jar/Attributes.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
! src/share/classes/sun/launcher/LauncherHelper.java
! src/share/classes/sun/launcher/resources/launcher.properties
! src/share/classes/sun/misc/JavaUtilJarAccess.java
! src/share/classes/sun/misc/URLClassPath.java
! src/share/classes/sun/misc/Version.java.template
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/resources/jar.properties
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java

Changeset: b7b0beef5ded
Author:    alanb
Date:      2013-08-15 13:42 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b7b0beef5ded

8015765: TEST_BUG: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failing intermittently
Reviewed-by: chegar, dholmes, alanb
Contributed-by: yiming.wang at oracle.com

! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java

Changeset: 7d7d553a8c61
Author:    igerasim
Date:      2013-08-13 13:04 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7d7d553a8c61

8022584: Memory leak in some NetworkInterface methods
Reviewed-by: alanb, dholmes, chegar, michaelm

! src/solaris/native/java/net/NetworkInterface.c
+ test/java/net/NetworkInterface/MemLeakTest.java

Changeset: 3223342fb76e
Author:    dl
Date:      2013-08-15 15:01 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3223342fb76e

8023103: FJ parallelism zero
8020537: java/util/concurrent/forkjoin/ThrowingRunnable.java
Reviewed-by: chegar, mduigou, alanb

! src/share/classes/java/util/concurrent/ForkJoinPool.java

Changeset: b07b19182e40
Author:    dl
Date:      2013-08-15 15:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b07b19182e40

8023104: ConcurrentHashMap typo
Reviewed-by: chegar, mduigou

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java

Changeset: e7137695dce3
Author:    chegar
Date:      2013-08-15 15:16 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e7137695dce3

8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress
Reviewed-by: smarks, alanb, michaelm, darcy

! src/share/classes/java/net/DatagramPacket.java

Changeset: 6c307b4d0dd8
Author:    sherman
Date:      2013-08-15 10:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6c307b4d0dd8

7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException
Summary: to add the throws clause
Reviewed-by: alanb, chegar

! src/share/classes/java/util/zip/Adler32.java
! src/share/classes/java/util/zip/CRC32.java

Changeset: b4645069238a
Author:    vinnie
Date:      2013-08-15 19:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b4645069238a

8023108: Remove ShortRSAKey1024.sh from ProblemList.txt
Reviewed-by: mullan

! test/ProblemList.txt

Changeset: 3211caab58ba
Author:    vinnie
Date:      2013-08-15 19:56 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3211caab58ba

Merge


Changeset: 5bb196aa183c
Author:    dxu
Date:      2013-08-15 12:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5bb196aa183c

4858457: File.getCanonicalPath() throws IOException when invoked with "nul" (win)
Reviewed-by: alanb

! src/windows/native/java/io/canonicalize_md.c
! test/java/io/File/WinDeviceName.java

Changeset: 0d27309a87e0
Author:    dxu
Date:      2013-08-15 14:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0d27309a87e0

8017109: Cleanup overrides warning in src/solaris/classes/sun/print/AttributeClass.java
Reviewed-by: jgodinez

! src/solaris/classes/sun/print/AttributeClass.java

Changeset: 5649837a4cfa
Author:    briangoetz
Date:      2013-08-12 12:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5649837a4cfa

8019401: Collectors.collectingAndThen
Reviewed-by: mduigou
Contributed-by: brian.goetz at oracle.com

! src/share/classes/java/util/stream/Collectors.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java

Changeset: 5fe19566b6f0
Author:    psandoz
Date:      2013-08-16 12:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5fe19566b6f0

8023150: java/util/stream tests no longer compiling following JDK-8019401
Reviewed-by: alanb

! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java

Changeset: 2eebaff52a94
Author:    psandoz
Date:      2013-08-16 12:46 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2eebaff52a94

8012940: More than 50 tests failed in Serialization/DeSerialization testing (test-mangled)
Reviewed-by: ksrini

+ test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
! test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java

Changeset: 02ce5a0e4b98
Author:    psandoz
Date:      2013-08-16 12:46 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/02ce5a0e4b98

8022898: java/util/Spliterator/SpliteratorCollisions.java fails in HashableIntSpliteratorWithNull data provider
Reviewed-by: henryjen, alanb, rriggs

! test/java/util/Spliterator/SpliteratorCollisions.java

Changeset: 737b6c298d81
Author:    psandoz
Date:      2013-08-13 11:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/737b6c298d81

8022797: Clarify spliterator characteristics for collections containing no elements
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Collection.java

Changeset: 53819fd0ab61
Author:    rriggs
Date:      2013-08-16 11:28 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/53819fd0ab61

8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing
8022766: java/time/test/java/time/chrono/TestUmmAlQuraChronology.java failed.
Summary: TCKChronology: corrected display name to match update from JDK-8015986
Reviewed-by: alanb

! test/java/time/tck/java/time/chrono/TCKChronology.java
! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java

Changeset: d7fc4e149bb8
Author:    rriggs
Date:      2013-08-16 11:11 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d7fc4e149bb8

8022193: java/time/test/java/util/TestFormatter.java failed in th locale.
Summary: Tests corrected to use fixed locale and not dependent on the environment
Reviewed-by: sherman

! src/share/classes/java/util/Formatter.java
! test/java/time/test/java/util/TestFormatter.java

Changeset: acaa256e3f7c
Author:    rriggs
Date:      2013-08-16 13:58 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/acaa256e3f7c

8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate
Summary: align Meiji start date with lib/calendar.properties to avoid any confusion
Reviewed-by: sherman

! src/share/classes/java/time/chrono/JapaneseEra.java

Changeset: 9e9f5713b26d
Author:    psandoz
Date:      2013-08-06 14:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9e9f5713b26d

8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls
Reviewed-by: chegar
Contributed-by: Martin Buchholz <martinrb at google.com>, Paul Sandoz <paul.sandoz at oracle.com>

! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/concurrent/package-info.java

Changeset: 8e098a29ecd8
Author:    egahlin
Date:      2013-08-16 17:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8e098a29ecd8

6417702: Graph in Memory tab is not redrawn immediately if changed via 'Chart' combo box
Reviewed-by: alanb, jbachorik, sjiang

! src/share/classes/sun/tools/jconsole/MemoryTab.java

Changeset: c67cb9d4d51a
Author:    egahlin
Date:      2013-08-16 17:11 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c67cb9d4d51a

6721425: jconsole Makefile clean rule is missing rm of generated Version.java
Reviewed-by: alanb, jbachorik

! make/sun/jconsole/Makefile

Changeset: 89ef4bcf7b0e
Author:    egahlin
Date:      2013-08-16 16:53 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/89ef4bcf7b0e

7015157: String "Tabular Navigation" should be rephrased for avoiding mistranslation
Reviewed-by: alanb, jbachorik, sjiang

! src/share/classes/sun/tools/jconsole/resources/messages.properties

Changeset: 71bad9540825
Author:    egahlin
Date:      2013-08-16 18:58 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/71bad9540825

6696970: Jconsole becomes unusable if a plugin throws an exception
Reviewed-by: mchung, jbachorik

+ src/share/classes/sun/tools/jconsole/ExceptionSafePlugin.java
! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/VMPanel.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties

Changeset: 11ccaabdb2a8
Author:    aefimov
Date:      2013-08-16 18:41 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/11ccaabdb2a8

8021820: Number of opened files used in select() is limited to 1024 [macosx]
Reviewed-by: alanb, chegar, tbell, smarks

+ test/java/net/ServerSocket/SelectFdsLimit.java

Changeset: f580728b08b4
Author:    alanb
Date:      2013-08-19 11:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f580728b08b4

8023215: test/java/util/Comparator/TypeTest.java not running (failing but reported as passing)
Reviewed-by: psandoz

! test/java/util/Comparator/TypeTest.java

Changeset: 3647aab7b1d5
Author:    psandoz
Date:      2013-08-06 14:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3647aab7b1d5

8014824: Document Spliterator characteristics and binding policy of java util collection impls
Reviewed-by: chegar

! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/LinkedHashMap.java
! src/share/classes/java/util/LinkedHashSet.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java

Changeset: bce5205dbe84
Author:    ascarpino
Date:      2013-08-14 10:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bce5205dbe84

8022669: OAEPParameterSpec does not work if MGF1ParameterSpec is set to SHA2 algorithms
Reviewed-by: mullan

! src/share/classes/sun/security/rsa/RSAPadding.java
! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java

Changeset: b40d246d4d81
Author:    ascarpino
Date:      2013-08-16 12:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b40d246d4d81

8022896: test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java fails
Reviewed-by: mullan

! test/ProblemList.txt

Changeset: 2fd841fccb2e
Author:    dxu
Date:      2013-08-19 12:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2fd841fccb2e

8023203: Wrap RandomAccessFile.seek native method into a Java helper method
Reviewed-by: alanb, chegar

! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/share/classes/java/io/RandomAccessFile.java
! src/share/native/java/io/RandomAccessFile.c

Changeset: f120e2c4b4b1
Author:    mullan
Date:      2013-08-19 17:17 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f120e2c4b4b1

8016850: JCK javax.security.auth.Policy tests fail when run in Profiles mode
Summary: Move default javax.security.auth.Policy implementation to compact1 profile
Reviewed-by: vinnie

! src/share/classes/com/sun/security/auth/PolicyFile.java
- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
! src/share/classes/javax/security/auth/Policy.java
+ src/share/classes/sun/security/provider/AuthPolicyFile.java
+ src/share/classes/sun/security/provider/SubjectCodeSource.java

Changeset: 096e7c665857
Author:    xuelei
Date:      2013-08-19 17:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/096e7c665857

8020842: IDN do not throw IAE when hostname ends with a trailing dot
Reviewed-by: weijun, michaelm

! src/share/classes/java/net/IDN.java
+ test/java/net/IDN/IllegalArg.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java

Changeset: 21a25911f7f7
Author:    xuelei
Date:      2013-08-19 18:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/21a25911f7f7

8023230: The impl of KerberosClientKeyExchange maybe not exist
Reviewed-by: weijun

! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java

Changeset: 53ea4b5cef9b
Author:    sla
Date:      2013-08-20 08:59 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/53ea4b5cef9b

8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual machine
Reviewed-by: erikj, sspitsyn

! makefiles/CompileNativeLibraries.gmk
+ makefiles/mapfiles/libattach/reorder-windows-x86
+ makefiles/mapfiles/libattach/reorder-windows-x86_64
! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c

Changeset: e17da8b09f5e
Author:    dholmes
Date:      2013-08-20 03:18 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e17da8b09f5e

8023311: Clean up profile-includes.txt
Reviewed-by: alanb

! makefiles/profile-includes.txt

Changeset: 961cdea684b5
Author:    sla
Date:      2013-08-20 16:53 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/961cdea684b5

8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently
Reviewed-by: alanb

! test/com/sun/jdi/sde/TemperatureTableTest.java

Changeset: c17d6543b30f
Author:    psandoz
Date:      2013-08-20 17:36 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c17d6543b30f

8023367: Collections.emptyList().sort((Comparator)null) throws NPE
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Collections.java
! test/java/util/Collection/ListDefaults.java

Changeset: 1ccc7bbee0bb
Author:    attila
Date:      2013-08-20 11:15 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1ccc7bbee0bb

8023250: Update JavaScript code in JDK for changes in iteration over Java arrays
Reviewed-by: sundar, sla

! src/share/classes/com/sun/tools/hat/resources/hat.js

Changeset: a79fcf53195f
Author:    lana
Date:      2013-08-20 17:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a79fcf53195f

Merge

- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java

Changeset: 9626ba160e3d
Author:    lana
Date:      2013-08-23 14:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9626ba160e3d

Merge

- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java

Changeset: 0417358184a1
Author:    omajid
Date:      2013-08-22 16:00 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0417358184a1

8023480: Create a jvm.cfg for zero on 32 bit architectures
Reviewed-by: dholmes, erikj

! makefiles/CopyFiles.gmk

Changeset: 1fe211ae3d2b
Author:    katleman
Date:      2013-08-26 17:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1fe211ae3d2b

Merge


Changeset: 1a2a8d143583
Author:    cl
Date:      2013-08-29 09:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1a2a8d143583

Added tag jdk8-b105 for changeset 1fe211ae3d2b

! .hgtags


From lois.foltan at oracle.com  Thu Aug 29 14:58:35 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 29 Aug 2013 17:58:35 -0400
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F97EE.9060407@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521F97EE.9060407@oracle.com>
Message-ID: <521FC40B.1070302@oracle.com>


Thank you Coleen for the review.

Lois

On 8/29/2013 2:50 PM, Coleen Phillimore wrote:
>
> Lois,
>
> This does looks better than the NOEXCEPT macros.  Can other people 
> review this today?  We need this for the clang c++ compiler upgrade 
> testing.
>
> Thanks,
> Coleen
>
> On 08/29/2013 02:33 PM, Lois Foltan wrote:
>>
>> Please review the following updated webrev:
>>
>> Internal webrev:
>>
>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>>
>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>          runtime/6878713/Test6878713.sh fails on mac
>>
>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>
>> Summary of fix:
>>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
>> command line option to the llvm-g++ compiler.
>>     The -fcheck-new option directs the compiler to "check that the 
>> pointer returned by |operator new| is non-null
>>      before attempting to modify the storage allocated."  The clang++ 
>> compiler does not support the
>>      -fcheck-new option.  To obtain similiar functionality when 
>> building Hotspot with clang++, empty exception
>>      throw() specifications must be added to all user-defined 
>> operator new()'s.
>>
>> Tests:
>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, 
>> MacOS (llvm-g++ & clang++)
>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>
>> Original Testing:
>>      Solaris: built fastdebug & product images
>>      Linux: built fastdebug & product images
>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>                     built fastdebug & product images using clang++ - 
>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>      Windows:  built fastdebug & product images with VS2010
>>
>> Thank you,
>> Lois
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/73660b92/attachment.html 

From lois.foltan at oracle.com  Thu Aug 29 15:01:22 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 29 Aug 2013 18:01:22 -0400
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F9AC5.8050504@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521F97EE.9060407@oracle.com> <521F9AC5.8050504@oracle.com>
Message-ID: <521FC4B2.5070007@oracle.com>

Thank you Harold for the review.

Lois

On 8/29/2013 3:02 PM, harold seigel wrote:
> Hi Lois,
>
> The changes look good.
>
> Thanks, Harold
>
> On 8/29/2013 2:50 PM, Coleen Phillimore wrote:
>>
>> Lois,
>>
>> This does looks better than the NOEXCEPT macros.  Can other people 
>> review this today?  We need this for the clang c++ compiler upgrade 
>> testing.
>>
>> Thanks,
>> Coleen
>>
>> On 08/29/2013 02:33 PM, Lois Foltan wrote:
>>>
>>> Please review the following updated webrev:
>>>
>>> Internal webrev:
>>>
>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>>>
>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>>          runtime/6878713/Test6878713.sh fails on mac
>>>
>>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>
>>> Summary of fix:
>>>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
>>> command line option to the llvm-g++ compiler.
>>>     The -fcheck-new option directs the compiler to "check that the 
>>> pointer returned by |operator new| is non-null
>>>      before attempting to modify the storage allocated." The clang++ 
>>> compiler does not support the
>>>      -fcheck-new option.  To obtain similiar functionality when 
>>> building Hotspot with clang++, empty exception
>>>      throw() specifications must be added to all user-defined 
>>> operator new()'s.
>>>
>>> Tests:
>>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, 
>>> MacOS (llvm-g++ & clang++)
>>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>>
>>> Original Testing:
>>>      Solaris: built fastdebug & product images
>>>      Linux: built fastdebug & product images
>>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>>                     built fastdebug & product images using clang++ - 
>>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>>      Windows:  built fastdebug & product images with VS2010
>>>
>>> Thank you,
>>> Lois
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/1ab6d38e/attachment.html 

From lois.foltan at oracle.com  Thu Aug 29 15:04:15 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 29 Aug 2013 18:04:15 -0400
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F9EE2.2000403@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521F97EE.9060407@oracle.com> <521F9EE2.2000403@oracle.com>
Message-ID: <521FC55F.4080205@oracle.com>

HI Calvin,

Thank you for the review.  And I just saw Harold's subsequent email.  He 
was correct.  I removed a space between "throw" and "()".

Lois


On 8/29/2013 3:20 PM, Calvin Cheung wrote:
> Hi Lois,
>
> src/share/vm/code/nmethod.cpp
>
> 803 void* nmethod::operator new(size_t size, int nmethod_size) throw() {
>
> The above line looks the same to me after the change.
> So perhaps the file doesn't need to be changed (other than the 
> copyright year)?
>
> Calvin
>
> On 8/29/2013 11:50 AM, Coleen Phillimore wrote:
>>
>> Lois,
>>
>> This does looks better than the NOEXCEPT macros.  Can other people 
>> review this today?  We need this for the clang c++ compiler upgrade 
>> testing.
>>
>> Thanks,
>> Coleen
>>
>> On 08/29/2013 02:33 PM, Lois Foltan wrote:
>>>
>>> Please review the following updated webrev:
>>>
>>> Internal webrev:
>>>
>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>>>
>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>>          runtime/6878713/Test6878713.sh fails on mac
>>>
>>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>
>>> Summary of fix:
>>>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
>>> command line option to the llvm-g++ compiler.
>>>     The -fcheck-new option directs the compiler to "check that the 
>>> pointer returned by |operator new| is non-null
>>>      before attempting to modify the storage allocated." The clang++ 
>>> compiler does not support the
>>>      -fcheck-new option.  To obtain similiar functionality when 
>>> building Hotspot with clang++, empty exception
>>>      throw() specifications must be added to all user-defined 
>>> operator new()'s.
>>>
>>> Tests:
>>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, 
>>> MacOS (llvm-g++ & clang++)
>>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>>
>>> Original Testing:
>>>      Solaris: built fastdebug & product images
>>>      Linux: built fastdebug & product images
>>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>>                     built fastdebug & product images using clang++ - 
>>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>>      Windows:  built fastdebug & product images with VS2010
>>>
>>> Thank you,
>>> Lois
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/e6e7eddf/attachment.html 

From lois.foltan at oracle.com  Thu Aug 29 15:13:45 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 29 Aug 2013 18:13:45 -0400
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521FA1F5.80301@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521FA1F5.80301@oracle.com>
Message-ID: <521FC799.7010308@oracle.com>


On 8/29/2013 3:33 PM, Daniel D. Daugherty wrote:
> On 8/29/13 12:33 PM, Lois Foltan wrote:
>>
>> Please review the following updated webrev:
>>
>> Internal webrev:
>
> Not an "internal" webrev. :-)
Hi Dan,
Noted, will pay attention to wording in future RFRs.
>
>
>>
>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>
> src/share/vm/adlc/arena.cpp
> src/share/vm/adlc/arena.hpp
> src/share/vm/adlc/main.cpp
> src/share/vm/asm/codeBuffer.hpp
> src/share/vm/c1/c1_Compilation.hpp
> src/share/vm/c1/c1_Instruction.hpp
> src/share/vm/code/codeBlob.cpp
> src/share/vm/code/codeBlob.hpp
> src/share/vm/code/debugInfoRec.cpp
> src/share/vm/code/nmethod.cpp
> src/share/vm/code/nmethod.hpp
> src/share/vm/code/relocInfo.hpp
> src/share/vm/code/vtableStubs.cpp
> src/share/vm/code/vtableStubs.hpp
> src/share/vm/gc_implementation/shared/gcUtil.hpp
> src/share/vm/libadt/port.hpp
> src/share/vm/memory/allocation.cpp
> src/share/vm/memory/allocation.hpp
> src/share/vm/memory/allocation.inline.hpp
> src/share/vm/memory/memRegion.cpp
> src/share/vm/memory/memRegion.hpp
> src/share/vm/oops/klass.cpp
> src/share/vm/oops/klass.hpp
> src/share/vm/oops/symbol.cpp
> src/share/vm/oops/symbol.hpp
> src/share/vm/opto/callGenerator.hpp
> src/share/vm/opto/callnode.hpp
> src/share/vm/opto/machnode.hpp
> src/share/vm/opto/node.hpp
> src/share/vm/opto/type.hpp
> src/share/vm/runtime/fprofiler.cpp
> src/share/vm/runtime/handles.cpp
> src/share/vm/runtime/handles.hpp
> src/share/vm/runtime/interfaceSupport.hpp
> src/share/vm/runtime/objectMonitor.hpp
> src/share/vm/runtime/park.cpp
> src/share/vm/runtime/park.hpp
> src/share/vm/runtime/thread.hpp
> src/share/vm/services/memRecorder.hpp
> src/share/vm/services/memTrackWorker.cpp
> src/share/vm/services/memTrackWorker.hpp
> src/share/vm/utilities/array.hpp
>     Yikes, this list is scary...
>
>     But I reviewed it via the patch link instead...
>
>     Changes are restricted to:
>
>     - additions of "throw()" in operator new() definitions
>       and operator new() declarations
>     - white space changes to make things line up
>     - copyright updates
>
>     Thumbs up!
>
>     I didn't try to verify that all the operator new() declarations
>     and definitions were covered. I don't know if there is an auto-magic
>     to perform such a verification.
No auto-magic, but I did make every attempt to go through the sources 
several times to make sure I correctly added a "throw()" to every new.
>
>     Please ping Vladimir Kozlov about this change so that PPC work
>     that is being done can also update their operator new() stuff.
Yes, Vladimir has commented on my change.  Thank you for your review!
Lois
>
> Dan
>
>
>
>>
>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced &
>>          runtime/6878713/Test6878713.sh fails on mac
>>
>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>
>> Summary of fix:
>>     On MacOS, currently Hotspot is built specifying the -fcheck-new 
>> command line option to the llvm-g++ compiler.
>>     The -fcheck-new option directs the compiler to "check that the 
>> pointer returned by |operator new| is non-null
>>      before attempting to modify the storage allocated."  The clang++ 
>> compiler does not support the
>>      -fcheck-new option.  To obtain similiar functionality when 
>> building Hotspot with clang++, empty exception
>>      throw() specifications must be added to all user-defined 
>> operator new()'s.
>>
>> Tests:
>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010, 
>> MacOS (llvm-g++ & clang++)
>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>
>> Original Testing:
>>      Solaris: built fastdebug & product images
>>      Linux: built fastdebug & product images
>>      MacOS:  built fastdebug & product images using llvm-g++ - ran JTREG
>>                     built fastdebug & product images using clang++ - 
>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>      Windows:  built fastdebug & product images with VS2010
>>
>> Thank you,
>> Lois
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130829/58dc0a70/attachment-0001.html 

From lois.foltan at oracle.com  Thu Aug 29 15:18:10 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 29 Aug 2013 18:18:10 -0400
Subject: RFR JDK-8021954 (round 2) VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521FC16A.6040601@oracle.com>
References: <521BA02E.6080901@oracle.com> <521F93F9.4040007@oracle.com>
	<521F97EE.9060407@oracle.com> <521F9EE2.2000403@oracle.com>
	<521FA227.3000305@oracle.com> <521FC16A.6040601@oracle.com>
Message-ID: <521FC8A2.7080700@oracle.com>


On 8/29/2013 5:47 PM, Vladimir Kozlov wrote:
> Lois,
>
> Never mind my previous comment. I missed that you added throw() to all 
> new() operators. The problem with ppc64 port was the missed throw() in 
> new() operator declaration in header file. And you fixed it. So I 
> think your changes are fine.
Hi Vladimir,
Thank you for the review.  Glad it provided the change you were 
interested in.
>
> I assume it passed JPRT (and all embedded) builds.
That is in progress and will be completed.
Lois

>
> thanks,
> Vladimir
>
> On 8/29/13 12:33 PM, Vladimir Kozlov wrote:
>> Lois,
>>
>> On 8/29/13 12:20 PM, Calvin Cheung wrote:
>>> Hi Lois,
>>>
>>> src/share/vm/code/nmethod.cpp
>>>
>>> 803 void* nmethod::operator new(size_t size, int nmethod_size) 
>>> throw() {
>>
>> Could you remove this throw()? As David pointed it was discussed and, we
>> think, it was added by mistake.
>>
>> thanks,
>> Vladimir
>>
>>>
>>> The above line looks the same to me after the change.
>>> So perhaps the file doesn't need to be changed (other than the 
>>> copyright
>>> year)?
>>>
>>> Calvin
>>>
>>> On 8/29/2013 11:50 AM, Coleen Phillimore wrote:
>>>>
>>>> Lois,
>>>>
>>>> This does looks better than the NOEXCEPT macros.  Can other people
>>>> review this today?  We need this for the clang c++ compiler upgrade
>>>> testing.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 08/29/2013 02:33 PM, Lois Foltan wrote:
>>>>>
>>>>> Please review the following updated webrev:
>>>>>
>>>>> Internal webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954.2/
>>>>>
>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file
>>>>> produced &
>>>>>          runtime/6878713/Test6878713.sh fails on mac
>>>>>
>>>>>     bug links at: https://bugs.openjdk.java.net/browse/JDK-8021954
>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>>
>>>>> Summary of fix:
>>>>>     On MacOS, currently Hotspot is built specifying the -fcheck-new
>>>>> command line option to the llvm-g++ compiler.
>>>>>     The -fcheck-new option directs the compiler to "check that the
>>>>> pointer returned by |operator new| is non-null
>>>>>      before attempting to modify the storage allocated." The clang++
>>>>> compiler does not support the
>>>>>      -fcheck-new option.  To obtain similiar functionality when
>>>>> building Hotspot with clang++, empty exception
>>>>>      throw() specifications must be added to all user-defined
>>>>> operator new()'s.
>>>>>
>>>>> Tests:
>>>>>      Built on Solaris (12u1), Linux (gcc 4.4.3 & 4.7.3), VS2010,
>>>>> MacOS (llvm-g++ & clang++)
>>>>>      Ran vm.quick.testlist on MacOS clang++ built Hotspot image
>>>>>
>>>>> Original Testing:
>>>>>      Solaris: built fastdebug & product images
>>>>>      Linux: built fastdebug & product images
>>>>>      MacOS:  built fastdebug & product images using llvm-g++ - ran
>>>>> JTREG
>>>>>                     built fastdebug & product images using clang++ -
>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist
>>>>>      Windows:  built fastdebug & product images with VS2010
>>>>>
>>>>> Thank you,
>>>>> Lois
>>>>>
>>>>
>>>


From ioi.lam at oracle.com  Thu Aug 29 15:37:10 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 29 Aug 2013 15:37:10 -0700
Subject: RFR (S) 8022335 - (round 2) Native stack walk on Windows x64
Message-ID: <521FCD16.10600@oracle.com>

Please review this fix:

http://cr.openjdk.java.net/~iklam/8022335/win64_stack_walk_002/

Bug: Native stack walk while generating hs_err does not work on Windows x64

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022335
     https://bugs.openjdk.java.net/browse/JDK-8022335

What's new:

     The code is much more simplified than my last version. All interesting
     code is in a single function -- os::platform_print_native_stack
     in os_windows_x86.cpp. The rest is just busy work.

Summary of fix:

     Windows x64 binaries are built (unconditionally) with the 
equivalent of
     -fomit-frame-pointer, so HotSpot's build-in native stack walking code
     will fail to find the sender frame. As a result, hs_err on Windows/x64
     will always list a single frame.

     I have added the os::platform_print_native_stack() function for
     Windows/x64 only. It uses the StackWalk64 API to walk the stace.

     Because the Win/x64 frame layout is very different than what 
HotSpot expects,
     I decided to implement os::platform_print_native_stack() as a 
completely
     stand-alone function, and do not interact with the existing "frame" 
C++ class.
     See comments in os_windows_x86.cpp for details.

Deficiency of fix:

     StackWalk64 knows nothing about the Java frames. So hs_err will 
display only
     the native frames, and stop as soon as the first Java frame is 
reached. It will
     also NOT display any native frames below Java frames.

     Printing the Java frames *may* be possible. However, at this point, 
I want
     to keep the code simple and crash proof. I will file a different 
bug for
     printing the Java frames.

Bonus:

     As a side-fix, I refactored a bunch of duplicated code in 
decoder.cpp into
     the DecoderLocker class.

Tests:

     JPRT
     UTE (vm.runtime.testlist, vm.quick.testlist, 
vm.parallel_class_loading.testlist)

     I also manually inserted some crashes into jvm.dll and verified 
that the
     native stack trace is printed as expected on Win/x64.


Thanks
- Ioi


From dmitry.samersoff at oracle.com  Thu Aug 29 14:40:08 2013
From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com)
Date: Thu, 29 Aug 2013 21:40:08 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130829214017.6D8C4623F4@hg.openjdk.java.net>

Changeset: d8e99408faad
Author:    dsamersoff
Date:      2013-08-29 21:48 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d8e99408faad

8009062: poor performance of JNI AttachCurrentThread after fix for 7017193
Summary: don't re-evaluate stack bounds for main thread before install guard page
Reviewed-by: coleenp, dholmes, dlong

! src/os/linux/vm/os_linux.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
+ test/runtime/InitialThreadOverflow/DoOverflow.java
+ test/runtime/InitialThreadOverflow/invoke.cxx
+ test/runtime/InitialThreadOverflow/testme.sh

Changeset: cef1e56a4d88
Author:    dsamersoff
Date:      2013-08-29 21:46 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cef1e56a4d88

Merge



From david.holmes at oracle.com  Thu Aug 29 19:09:13 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 12:09:13 +1000
Subject: S RFR: Lambda: verification error in generated lambda classes
In-Reply-To: <CAFUO74=K1qZF7vu+ewdXcZpKxvbiS47uEHynMbsQX0kkjmutYg@mail.gmail.com>
References: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
	<521E9A45.8040809@oracle.com>
	<491B7272-B309-4193-BF8B-E7889441B6FB@oracle.com>
	<CAFUO74kYcSx5umWA_VY4Aq_R8UnHHcn3VaMsJ-N6qsuNKc4AtQ@mail.gmail.com>
	<8BA6AF53-D39D-4821-8D63-E936FA4592B2@oracle.com>
	<CAFUO74=K1qZF7vu+ewdXcZpKxvbiS47uEHynMbsQX0kkjmutYg@mail.gmail.com>
Message-ID: <521FFEC9.5050700@oracle.com>

On 30/08/2013 4:02 AM, Keith McGuigan wrote:
> I think there's an extra set of parenthesis that isn't needed, but other
> than that, thanks, looks good!

Agreed on all three counts (extra, not needed, good) :)

I still had to write out the truth table to be certain :)

Thanks,
David

>
> On Thu, Aug 29, 2013 at 1:29 PM, Karen Kinnear <Karen.Kinnear at oracle.com
> <mailto:Karen.Kinnear at oracle.com>> wrote:
>
>     Keith, David,
>
>     Many thanks for the suggestions. I think Keith's proposal is much
>     simpler to read. I did
>     a name change as well to hopefully make this more obvious.
>
>     webrev.02:
>>
>>         >> webrev: http://cr.openjdk.java.net/~acorn/8023872.02/webrev/
>>         >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>
>     I redid the manual testing, and the longer tests are in progress again.
>
>     thanks,
>     Karen
>
>     On Aug 28, 2013, at 10:31 PM, Keith McGuigan wrote:
>
>>     I think it's ok as it is, if you need to check it in quick, but I
>>     agree that this probably should be rewritten better to make the
>>     logic more obvious.  Maybe separate clauses for reflection/lambda
>>     code?
>>
>>         ((!is_MAI && !is_MLI) ||
>>         (is_MAI && VerifyReflectionBytecodes) ||
>>         (is_MLI && VerifyLambdaBytecodes))
>>
>>     Isn't this equivalent to:
>>       (!is_MAI || VerifyReflectionBytecodes) &&
>>       (!is_MLI || VerifyLambdaBytecodes)
>>
>>
>>
>>     On Wed, Aug 28, 2013 at 8:50 PM, Karen Kinnear
>>     <Karen.Kinnear at oracle.com <mailto:Karen.Kinnear at oracle.com>> wrote:
>>
>>         Thank you David. I agree, I was tempted to rewrite the entire
>>         method - in particular, in a debugger
>>         (so I didn't check the optimized code) we walk the entire &&
>>         before we make the initial call - in this
>>         case the initial call would weed out more things faster
>>         potentially, so ... But I chose not to rewrite since
>>         they need this quickly and the shaking out would take quite a
>>         bit longer.
>>
>>         thanks for the review,
>>         Karen
>>
>>         On Aug 28, 2013, at 8:48 PM, David Holmes wrote:
>>
>>         > Hi Karen,
>>         >
>>         > I found the boolean logic very hard to follow there - not
>>         sure if the refactoring helped or hindered :)
>>         >
>>         > But it looks okay.
>>         >
>>         > David
>>         >
>>         > On 29/08/2013 5:42 AM, Karen Kinnear wrote:
>>         >> Please review - lambda team needs this change to get in by
>>         tomorrow so
>>         >> they can push
>>         >> the (8010433) metafactory change which is waiting on the
>>         vm. Thanks.
>>         >>
>>         >>
>>         >> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
>>         >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>>         >>
>>         >> Testing:
>>         >> The failure comes if you apply an early patch of 8010433 to
>>         the jdk and
>>         >> do not
>>         >> make the vm change. So testing included 4 binaries: master,
>>         newjdk,
>>         >> newvm, newjdkvm
>>         >>
>>         >> jtreg for SpinedBufferTest with various flags - these are
>>         the expected
>>         >> results below
>>         >> The key point is newjdk -Xverify: all fails
>>         >> newjdkvm -Xverify:all passes, but if you also turn on
>>         >> -XX:+VerifyLambdaBytecodes you see
>>         >>    the verification error
>>         >>
>>         >> 1. master
>>         >>  no flags: timed out
>>         >>  -Xverify:all: timed out
>>         >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>         >>
>>         >> 2. newjdk
>>         >>  no flags: timed out
>>         >>  -Xverify:all
>>         >>    java.lang.BootstrapMethodError: call site initialization
>>         exception
>>         >> ... cause:
>>         >>      VerifyError: Bad invokespecial instruction: current
>>         class isn't
>>         >> assignable to reference class
>>         >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>         >>
>>         >> 3. newvm
>>         >>   no flags: timed out
>>         >>   rerun.sh: -Xverify:all: passed
>>         >>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>         >>   -XX:+VerifyLambdaBytecodes: passed, didn't try verification
>>         >>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
>>         >>
>>         >> 4. newjdkvm
>>         >>  rerun.sh: no flags: passed
>>         >> rerun.verify.sh <http://rerun.verify.sh/>: -Xverify:all: passed
>>         >>  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
>>         >>    Verification for
>>         java.util.streamIntPipeline$7$1$$Lambda$9 failed
>>         >>
>>         >> regression testing:
>>         >> newvm:
>>         >>   vm.quick.testlist - in progress
>>         >>   jtreg java/util/stream - in progress
>>         >>   jprt -stree . - in progress
>>         >>
>>         >> newvmjdk (Brian testing in lambda repo) - in progress
>>         >>
>>         >> thanks,
>>         >> Karen
>>         >>
>>
>>
>>
>>
>>     --
>>     - Keith McGuigan <keith.mcguigan at alumni.unh.edu
>>     <mailto:keith.mcguigan at alumni.unh.edu>>
>
>
>
>
> --
> - Keith McGuigan <keith.mcguigan at alumni.unh.edu
> <mailto:keith.mcguigan at alumni.unh.edu>>

From david.holmes at oracle.com  Thu Aug 29 19:18:56 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 12:18:56 +1000
Subject: RFR JDK-8022407 (round 2) sun/misc/CopyMemory.java fails with
	SIGSEGV in Unsafe_SetByte+0x35
In-Reply-To: <521F381B.5090005@oracle.com>
References: <521CD14D.5040809@oracle.com> <521E39DB.1050901@oracle.com>
	<521F2D7F.5030001@oracle.com> <521F381B.5090005@oracle.com>
Message-ID: <52200110.7030400@oracle.com>

On 29/08/2013 10:01 PM, Lois Foltan wrote:
>
> On 8/29/2013 7:16 AM, David Holmes wrote:
>> Hi Lois,
>>
>> Is this still needed:
>>
>>  142     PCH_FLAG/unsafe.o = $(PCH_FLAG/NO_PCH)
>>
>> given you no longer use -O0 ?
> Hi David,
> Yes, I believe so but this might be a cautionary change on my part. I
> read the comment to imply that Clang does not support a precompiled
> header compiled with an optimization level that is different than the
> one used to compile the actual C++ file, this is why I chose to add
> unsafe.o.

I read the comment as only applying to a combination of -O0 with -O3. So 
now the comment is inaccurate as it claims all files are compiled with -O0.

133     # There are some files which don't like precompiled headers
134     # The following files are build with 'OPT_CFLAGS/NOOPT' (-O0) in 
the opt build.
135     # But Clang doesn't support a precompiled header which was 
compiled with -O3
136     # to be used in a compilation unit which uses '-O0'. We could 
also prepare an
137     # extra '-O0' PCH file for the opt build and use it here, but 
it's probably
138     # not worth the effort as long as only two files need this 
special handling.

Either the comment or the entry at line 142 need to be changed. (the 
part about 'two files' is already out of date :( )

David
-----

> Lois
>
>> Thanks,
>> David
>>
>> On 29/08/2013 3:56 AM, Lois Foltan wrote:
>>>
>>> Please review the updated webrev:
>>>      open webrev at
>>> http://cr.openjdk.java.net/~hseigel/bug_jdk8022407.2/
>>>
>>> Bug:
>>>      bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>>
>>> Summary of fix:
>>>
>>>      The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++
>>> compiler, exhibited a compiler
>>>      optimization issue when prims/unsafe.cpp was compiled at the
>>> default -Os level. As a work around
>>>      fix, knock the optimization level down down to -O1.
>>>
>>> Tests: MacOS: built fastdebug & product images using clang++ (ran JTREG
>>> & vm.quick.testlist)
>>>            built using llvm-g++ to verifyprims/unsafe.cpp remained
>>> compiled at -Os
>>>
>>> Thank you, Lois
>>>
>>>
>

From david.holmes at oracle.com  Thu Aug 29 19:22:21 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 12:22:21 +1000
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <521F495C.9030900@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
	<521C9F11.5010809@oracle.com> <521D486E.8090207@oracle.com>
	<521E1D0D.80307@oracle.com> <521F2CBF.2090809@oracle.com>
	<521F495C.9030900@oracle.com>
Message-ID: <522001DD.8040106@oracle.com>

On 29/08/2013 11:15 PM, Lois Foltan wrote:
>
> On 8/29/2013 7:13 AM, David Holmes wrote:
>> On 29/08/2013 1:53 AM, Coleen Phillimore wrote:
>>> On 8/27/2013 8:46 PM, David Holmes wrote:
>>>> Thanks for the detailed explanation. It is frustrating that we keep
>>>> having to revisit these allocation routines.
>>>>
>>>> However it still seems to me that we don't need NO_EXCEPT on most of
>>>> our operator new definitions because they will never return NULL. This
>>>> is trivially so for things like:
>>>>
>>>>  void* StackObj::operator new(size_t size)     NOEXCEPT {
>>>> ShouldNotCallThis(); return 0; }
>>>> void* _ValueObj::operator new(size_t size)    NOEXCEPT {
>>>> ShouldNotCallThis(); return 0; }
>>>>
>>>> but also for anything that invokes vm_exit_out_of_memory directly or
>>>> indirectly.
>>>
>>> I don't think this is a good idea at all.   We want the constructor
>>> prologue to always check for null before calling the constructor. We
>>> will never throw C++ exceptions for these so all operator new's are
>>> NOEXCEPT.   These trivial examples would return zero rather than
>>> throwing if ShouldNotCallThis() is ifdef'ed out in product. So, this
>>> example is either trivially wrong without NOEXCEPT or correct without
>>> NOEXCEPT.   It is safer code to make them all NOEXCEPT.
>>
>> If the allocator can never return a NULL value then checking for NULL
>> is completely redundant.
> Hi David,
> We do have allocators that can return a NULL value, like
> MetaSpace::allocate(), Chunk's operator new(), etc.  Both demonstrating
> the return of NULL in the two bug reports.

Please re-read what I said. I know we do have allocators that return 
NULL. We also have allocators that DO NOT return NULL. The NULL check is 
only needed on the former, not the latter.

>> We don't check our internal allocation routines for NULL returns where
>> we know they abort on failure, so how is this any different ?
> Actually we have been checking NULL, it's just that the C++ compiler's
> have been implicitly checking NULL for us.  Solaris C++ generates by
> default NULL detection constructor prologue code for user-defined class
> member operator new() even in a throw situation. For gcc we specify
> -fcheck-new.  So whether or not we explicitly direct the compiler to
> check via an empty "throw()" specification or not, it's still being
> done.  So why should we check now?  Because we have a C++ compiler,
> clang, that adheres to the standard and doesn't support -fcheck-new.  It
> wants to be explicitly told.

See above.

Thanks,
David
------

>> AFAICS ShouldNotCallThis() is not ifdef'd out but if it were then yes
>> this would fail - as would ifdef'ing out a vm_exit_out_of_memory in
>> the other allocation routines.
>>> So really the only question is whether NOEXCEPT is better than
>>> throw().    throw() looks nicer because it's not a macro. NOEXCEPT may
>>> be required for the future if that's required to conditionally add the
>>> noexcept keyword.
>>>
>>> Maybe we should use throw() for now and worry about the noexcept keyword
>>> if that becomes an issue.
>>
>> It would be less ugly to use throw() but more intrusive in that it
>> affects all the compilers. Plus I don't know what the benefit would be
>> of moving from throw() to noexcept if they both mean the same thing?
> I believe the c++11 standard obsolesces "throw()" in favor of noexcept
> keyword.  However, I can't imagine that a compiler would completely
> obsolesce it, I can image there will be a mode to still support "throw()".
>
> Lois
>>
>>> David, where are you removing spurious throw() expressions and why?
>>
>> ./share/vm/code/nmethod.cpp:void* nmethod::operator new(size_t size,
>> int nmethod_size) throw () {
>>
>> See:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-August/010526.html
>>
>>
>> and subsequent replies. The presence of throw() was considered an
>> error at the time but now it seems not. I don't know if it has been
>> removed in hotspot-compiler, or perhaps just in the staging repos for
>> the ppc64 changes.
>>
>> Cheers,
>> David
>> ------
>>
>>
>>
>>> Thanks,
>>> Coleen
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 27/08/2013 10:44 PM, Lois Foltan wrote:
>>>>>
>>>>> On 8/27/2013 7:31 AM, David Holmes wrote:
>>>>>> On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
>>>>>>> On 2013-08-27 04:41, David Holmes wrote:
>>>>>>>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>>>>>>>> Please review the following fix:
>>>>>>>>>
>>>>>>>>> Internal webrev:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>>>>>>>
>>>>>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file
>>>>>>>>> produced &
>>>>>>>>>           runtime/6878713/Test6878713.sh fails on mac
>>>>>>>>>
>>>>>>>>>      bug links at:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8021954
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>>>>>>
>>>>>>>>> Summary of fix:
>>>>>>>>>      On MacOS, currently Hotspot is built specifying the
>>>>>>>>> -fcheck-new
>>>>>>>>> command line option to the llvm-g++ compiler.
>>>>>>>>>      The -fcheck-new option directs the compiler to "check that
>>>>>>>>> the
>>>>>>>>> pointer returned by |operator new| is non-null
>>>>>>>>>       before attempting to modify the storage allocated." The
>>>>>>>>> clang++
>>>>>>>>> compiler does not support the
>>>>>>>>>       -fcheck-new option.  To obtain similiar functionality when
>>>>>>>>> building Hotspot with clang++, empty exception
>>>>>>>>>       throw() specifications must be added to all user-defined
>>>>>>>>> operator
>>>>>>>>> new()'s.
>>>>>>>>
>>>>>>>> We just spotted something related in the PPC64 port and were going
>>>>>>>> the
>>>>>>>> other way or removing these "spurious" throw() declarations.
>>>>>>>>
>>>>>>>> But this seems really ugly - is there really a need to specialize
>>>>>>>> this
>>>>>>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ compilers
>>>>>>>> honour the nothrow() semantics?
>>>>>>>>
>>>>>>>> That said I thought we already handled this using the "const
>>>>>>>> std::nothrow_t&  nothrow_constant" where needed? Our other
>>>>>>>> operator new
>>>>>>>> implementations shouldn't return NULL but will abort.
>>>>>>>>
>>>>>>>> So why do we need -fcheck-new or this empty throw() ?
>>>>>>>
>>>>>>> I guess that if the C++ compiler knows that operator new() will
>>>>>>> throw an
>>>>>>> exception if an allocation fails then it doesn't need to emit
>>>>>>> code to
>>>>>>> explicitly avoid calling the constructor.
>>>>>>
>>>>>> Yes that is what happens, but why do _we_ need it when ...
>>>>>>
>>>>>>> If we declare operator new() with an empty throw() we will also
>>>>>>> inform
>>>>>>> the compiler that new can't throw an exception and therefore the
>>>>>>> compiler needs to explicitly handle failed allocations.
>>>>>>
>>>>>> ... we have two kinds of operator new implementations (or at least we
>>>>>> _should_ only have two kinds):
>>>>>>
>>>>>> 1. Will abort on OOM (either ResourceArea exhaustion or Stack
>>>>>> exhaustion) and so never returns NULL
>>>>>> 2. Can return NULL and uses std::nothrow to indicate that
>>>>>>
>>>>>> So we should not need this if the nothrow is acting as I think it
>>>>>> should. Have we missed places where nothrow is needed? Do we have
>>>>>> errant operator new definitions unrelated to the allocation base
>>>>>> classes?
>>>>> Hi David,
>>>>>
>>>>> I think there may be some confusion about what std::nothrow_t is
>>>>> actually doing.  It provides a mechanism to overload operator new &
>>>>> delete in order to direct the compiler to prefer a function definition
>>>>> that also should contain an empty "throw()" specification. Take for
>>>>> example the standard definition of the global ::operator new(). It
>>>>> actually looks like:
>>>>>
>>>>>   * void * operator new
>>>>> <a00960.html#a1414bcdb34c39ce82fc84bc8d5287966>
>>>>>     (std::size_t) throw (std::bad_alloc)
>>>>>   * void * operator new
>>>>> <a00960.html#a940b606c7824b4d5dd121199c277d629>
>>>>>     (std::size_t, const std::nothrow_t &) throw ()
>>>>>
>>>>> When the std::nothrow_t parameter is passed to the global ::operator
>>>>> new() the invoked function is the one that also contains an empty
>>>>> throw() specification.  It is due to this empty throw() specification
>>>>> that directs or triggers the C++ compiler to generate the detection of
>>>>> NULL constructor prologue.   Specifying only the std::nothrow_t
>>>>> parameter to a class member user-defined ::operator new() does not
>>>>> indicate to a C++ compiler that the function does not throw an
>>>>> exception.  According to the c++98 standard, a function that will
>>>>> throw
>>>>> no exceptions should be delcared with an empty "throw()" list
>>>>> specification.  When first experimenting with a fix, I did just try to
>>>>> overload Hotspot's user-defined operator new() with the std:nothrow_t
>>>>> parameter.  As expected, the mere presence of this parameter did not
>>>>> trigger the clang++ compiler to generate NULL detection constructor
>>>>> prologue code.  Unfortunately, probably due to legacy code, some C++
>>>>> compilers behave differently.  For example, I did confirm with Solaris
>>>>> C++ development, the Solaris C++ by default always generates
>>>>> constructor
>>>>> prologue code that detects NULL for class member user-defined operator
>>>>> new() even in a throw situation. G++ provides the -fcheck-new command
>>>>> line option.  It is due to these differences of behavior or Hotspot's
>>>>> build specification of -fcheck-new that has led us to believe that
>>>>> std::nothrow_t was providing something that it is not.
>>>>>
>>>>> That said, I would also prefer what you propose, deciding on two kinds
>>>>> of operator new()'s that can be defined.  I did examine all of the
>>>>> user-defined operator new()'s within the code and I determined that
>>>>> only
>>>>> a very small number possibly could not return NULL.  Given this,
>>>>> factored in with the historical reliance on -fcheck-new for the g++
>>>>> compilers, I decided the safe route for JDK 8 was to introduce the
>>>>> NOEXCEPT macro.
>>>>>
>>>>> Lois
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> The g++ man page states:
>>>>>>>
>>>>>>>         -fcheck-new
>>>>>>>             Check that the pointer returned by "operator new" is
>>>>>>> non-null before attempting to modify the storage allocated. This
>>>>>>> check
>>>>>>> is normally unnecessary because the C++ standard specifies that
>>>>>>>             "operator new" will only return 0 if it is declared
>>>>>>> throw(),
>>>>>>> in which case the compiler will always check the return value even
>>>>>>> without this option.  In all other cases, when "operator new"
>>>>>>>             has a non-empty exception specification, memory
>>>>>>> exhaustion
>>>>>>> is signalled by throwing "std::bad_alloc".  See also new (nothrow).
>>>>>>>
>>>>>>> /Mikael
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Tests:
>>>>>>>>>
>>>>>>>>>       Solaris: built fastdebug & product images
>>>>>>>>>       Linux: built fastdebug & product images
>>>>>>>>>       MacOS:  built fastdebug & product images using llvm-g++ -
>>>>>>>>> ran
>>>>>>>>> JTREG
>>>>>>>>>                      built fastdebug & product images using
>>>>>>>>> clang++ -
>>>>>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>>>>>>>       Windows:  built fastdebug & product images with VS2010
>>>>>>>>>
>>>>>
>>>
>

From david.holmes at oracle.com  Thu Aug 29 19:24:28 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 12:24:28 +1000
Subject: RFR S 8023381: VM fails to initialize in
	runtime/CDSCompressedKPtrs/XShareAuto.java
	runtime/SharedArchiveFile/CdsSameObjectAlignment.java
In-Reply-To: <521F9674.8050703@oracle.com>
References: <521F9674.8050703@oracle.com>
Message-ID: <5220025C.5030107@oracle.com>

Looks good to me too!

David

On 30/08/2013 4:44 AM, harold seigel wrote:
> Hi,
>
> Please review this small change to fix a problem with some of the JTreg
> CDS tests.  The fix changes the tests to look for a more generic reason
> for why the JVM could not use CDS, causing it to exit.  The tests now
> look for "Unable to use shared archive".  This message is always printed
> when the JVM exits because it could not use CDS.
>
> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8023381/
> <http://cr.openjdk.java.net/%7Ehseigel/bug_8023381/>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8023381
>
> The fixed tests were run on Linux 32 and 64 bit, Solaris Sparc 10 and
> 11, Solaris x86 10, Mac OS X, and Windows.
>
> Thanks! Harold
>

From coleen.phillimore at oracle.com  Thu Aug 29 19:22:50 2013
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 30 Aug 2013 02:22:50 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8021954: VM SIGSEGV during classloading
	on MacOS; hs_err_pid file produced
Message-ID: <20130830022258.BC07862404@hg.openjdk.java.net>

Changeset: 9758d9f36299
Author:    coleenp
Date:      2013-08-29 18:56 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9758d9f36299

8021954: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced
Summary: declare all user-defined operator new()s within Hotspot code with the empty throw() exception specification
Reviewed-by: coleenp, twisti, dholmes, hseigel, dcubed, kvn, ccheung
Contributed-by: lois.foltan at oracle.com

! src/share/vm/adlc/arena.cpp
! src/share/vm/adlc/arena.hpp
! src/share/vm/adlc/main.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/debugInfoRec.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/relocInfo.hpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/code/vtableStubs.hpp
! src/share/vm/gc_implementation/shared/gcUtil.hpp
! src/share/vm/libadt/port.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/memRegion.cpp
! src/share/vm/memory/memRegion.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/symbol.cpp
! src/share/vm/oops/symbol.hpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/machnode.hpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/fprofiler.cpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/runtime/objectMonitor.hpp
! src/share/vm/runtime/park.cpp
! src/share/vm/runtime/park.hpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/services/memRecorder.hpp
! src/share/vm/services/memTrackWorker.cpp
! src/share/vm/services/memTrackWorker.hpp
! src/share/vm/utilities/array.hpp


From david.holmes at oracle.com  Thu Aug 29 20:28:50 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 13:28:50 +1000
Subject: [Fwd: Re: RFR (M/L): 8010722 assert: failed: heap size is too
	big for compressed oops]
In-Reply-To: <1377786480.4272.12.camel@cirrus>
References: <1377786480.4272.12.camel@cirrus>
Message-ID: <52201172.1070002@oracle.com>

Hi Thomas,

I think it is bad form to call os::init_large_pages() from inside the 
arguments processing code! I presume you can not move it from 
os::init_2() to os::init()? I'd prefer to see the argument processing 
refactored if we have to add in another os::init hook, than to hide this 
inside the argument processing.

David

On 30/08/2013 12:28 AM, Thomas Schatzl wrote:
> Hi all,
>
>    forwarding the RFR for 8010722 here too as it contains changes on
> parts of the runtime too (argument processing, large page
> initialization), and you might be interested.
>
> Note that the current webrev is
> http://cr.openjdk.java.net/~tschatzl/8010722/webrev.3
>
> Sorry for not thinking about cc'ing here earlier,
>    Thomas
>
> -------- Forwarded Message --------
>> From: Thomas Schatzl <thomas.schatzl at oracle.com>
>> To: hotspot-gc-dev at openjdk.java.net
>> Subject: Re: RFR (M/L): 8010722 assert: failed: heap size is too big
>> for compressed oops
>> Date: Wed, 28 Aug 2013 15:32:46 +0200
>>
>> Hi all,
>>
>> On Tue, 2013-05-14 at 16:37 +0200, Thomas Schatzl wrote:
>>> Hi all,
>>>
>> JIRA:
>>> https://jbs.oracle.com/bugs/browse/JDK-8010722
>>
>>   can I have reviews for the following change?
>>
>>>
>>> In argument processing related to ergonomically determining compressed
>>> oops use, there were a few use-before-set issues leading to crashes that
>>> this fix tries to resolve.
>>>
>>> bugs.sun.com
>>> http://bugs.sun.com/view_bug.do?bug_id=8010722
>>>
>>> JIRA:
>>> https://jbs.oracle.com/bugs/browse/JDK-8010722
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8010722/webrev.1/
>>
>> There is a new webrev at
>> http://cr.openjdk.java.net/~tschatzl/8010722/webrev.2 ; this has become
>> necessary after the changes in CR 8007074 (Stefan K's large pages
>> changes) and CR 8003424 from Harold.
>>
>> Particularly the latter changed how the class metadata space is
>> allocated, removing a lot of additional checking and alignment issues.
>>
>> However the core issue still persists, the maximum heap size for
>> compressed oops is calculated wrongly as the NULL page is not properly
>> accounted for.
>>
>> testing:
>> jprt, jprt test cases
>>
>> Thomas
>>
>>> Here's a walkthrough of the changes:
>>>
>>> As mentioned, the cause of this CR is that ergonomics for determining
>>> the maximum java heap size usable for compressed oops uses variables
>>> that are later changed ergonomically.
>>>
>>> It is best to look at the changes beginning from
>>> Arguments::set_ergonomics_flags(): the idea of this change is to avoid
>>> later overflow, so the change tries to conservatively estimate sizes of
>>> the non-java heap parts. The complication is that not even the later
>>> effective alignment of these heap parts has been determined at this
>>> point.
>>>
>>> So the change first calculates the maximum possible heap alignment by
>>> calling set_max_heap_alignment(); this size is influenced by OS page
>>> sizes, so the change needs to initialize large pages by calling
>>> os::large_page_init() in Arguments::parse(), before the call to
>>> set_ergonomics_flags(). The maximum possible alignment is then
>>> calculated by asking the active GC for its maximum alignment, as at this
>>> point the GC has already been determined, the maximum page size, and
>>> other requirements, like alignment for card table size etc.
>>>
>>> Now the code can calculate the conservative estimate for actual maximum
>>> heap for compressed oops used in set_use_compressed_oops(), by
>>> subtracting the conservatively aligned sizes of the other heap parts.
>>> (In Arguments::max_heap_for_compressed_oops()) The result is the maximum
>>> possible heap that can use compressed oops, minus the aligned metaspace
>>> size, minus the aligned null page size.
>>>
>>> There is another circular dependency problem here, the metaspace size itself is later ergonomically sized; the change fixes this problem by anticipating that in Arguments::max_heap_for_compressed_oops(), using the same predicate for determining whether to ergonomically size it or not [this is CR8009778 I think].
>>>
>>> The other changes are straightforward: the os_* changes result from that
>>> large page initialization must be done earlier now; the changes in the
>>> collectors themselves are simply about providing the collector's maximum
>>> alignment. The change in Universe::reserve_heap() contains one assertion that checks whether the conservative estimate for alignment has been conservative enough earlier.
>>>
>>> The test case tests test cases from the CR that work now, and additional
>>> border cases related to ergonomically deciding heap size for compressed
>>> oops.
>>>
>>> One side effect of this change is that the ergonomically determined heap size is slighly smaller now (so that it always fits :).
>>>
>>> Thanks,
>>>    Thomas
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>

From david.holmes at oracle.com  Thu Aug 29 20:33:52 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 13:33:52 +1000
Subject: RFR: 6991327 : using -Xprof trigger native memory leak
In-Reply-To: <521F8A72.3080609@oracle.com>
References: <521F8A72.3080609@oracle.com>
Message-ID: <522012A0.4060305@oracle.com>

Looks okay to me.

Thanks,
David

On 30/08/2013 3:52 AM, Zhengyu Gu wrote:
> The is a simple fix for memory leak.
>
> FlatProfiler::record_thread_tick allocates array for JavaThread list,
> but never free it.
>
>
> External bug: http://bugs.sun.com/view_bug.do?bug_id=6991327
> Internal bug: https://bugs.openjdk.java.net/browse/JDK-6991327
> Webrev: http://cr.openjdk.java.net/~zgu/6991327/webrev.00/
> <http://cr.openjdk.java.net/%7Ezgu/6991327/webrev.00/>
>
> Test:
>    Ran test case (2) on bug report with NMT detail tracking on Linux 32,
> diff report clearly shows memory leak at
> FlatProfiler::record_thread_tick().  pmap also shows total memory grows
> continuously.
>
>    With the fix, the call site no longer shows on diff report, and there
> are not obviously memory leaks on the report. pmap shows total memory
> stops growing after a while.
>
> Sanity check:
>    Passed JPRT with -Xprof flag
>
> Thanks,
>
> -Zhengyu
>

From thomas.schatzl at oracle.com  Thu Aug 29 23:22:21 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 30 Aug 2013 08:22:21 +0200
Subject: [Fwd: Re: RFR (M/L): 8010722 assert: failed: heap size is too
	big for compressed oops]
In-Reply-To: <52201172.1070002@oracle.com>
References: <1377786480.4272.12.camel@cirrus> <52201172.1070002@oracle.com>
Message-ID: <1377843741.2449.5.camel@cirrus>

Hi David,

On Fri, 2013-08-30 at 13:28 +1000, David Holmes wrote:
> Hi Thomas,
> 
> I think it is bad form to call os::init_large_pages() from inside the 
> arguments processing code! I presume you can not move it from 
> os::init_2() to os::init()? I'd prefer to see the argument processing 

We need it initialized somewhere after arguments processing and before
doing ergonomics, when determining the maximum heap size that is
available to support compressed oops.

This needs to take the system's page sizes into account, which need to
be initialized first.

There have been similar concerns about that from others that it is not
particularly nice, but at this stage we did not see another choice.

> refactored if we have to add in another os::init hook, than to hide this 
> inside the argument processing.

Okay, I will do that and prepare another patch.

> 
> David

Thanks a lot for your input,
  Thomas


> 
> On 30/08/2013 12:28 AM, Thomas Schatzl wrote:
> > Hi all,
> >
> >    forwarding the RFR for 8010722 here too as it contains changes on
> > parts of the runtime too (argument processing, large page
> > initialization), and you might be interested.
> >
> > Note that the current webrev is
> > http://cr.openjdk.java.net/~tschatzl/8010722/webrev.3
> >
> > Sorry for not thinking about cc'ing here earlier,
> >    Thomas
> >
> > -------- Forwarded Message --------
> >> From: Thomas Schatzl <thomas.schatzl at oracle.com>
> >> To: hotspot-gc-dev at openjdk.java.net
> >> Subject: Re: RFR (M/L): 8010722 assert: failed: heap size is too big
> >> for compressed oops
> >> Date: Wed, 28 Aug 2013 15:32:46 +0200
> >>
> >> Hi all,
> >>
> >> On Tue, 2013-05-14 at 16:37 +0200, Thomas Schatzl wrote:
> >>> Hi all,
> >>>
> >> JIRA:
> >>> https://jbs.oracle.com/bugs/browse/JDK-8010722
> >>
> >>   can I have reviews for the following change?
> >>
> >>>
> >>> In argument processing related to ergonomically determining compressed
> >>> oops use, there were a few use-before-set issues leading to crashes that
> >>> this fix tries to resolve.
> >>>
> >>> bugs.sun.com
> >>> http://bugs.sun.com/view_bug.do?bug_id=8010722
> >>>
> >>> JIRA:
> >>> https://jbs.oracle.com/bugs/browse/JDK-8010722
> >>>
> >>> webrev:
> >>> http://cr.openjdk.java.net/~tschatzl/8010722/webrev.1/
> >>
> >> There is a new webrev at
> >> http://cr.openjdk.java.net/~tschatzl/8010722/webrev.2 ; this has become
> >> necessary after the changes in CR 8007074 (Stefan K's large pages
> >> changes) and CR 8003424 from Harold.
> >>
> >> Particularly the latter changed how the class metadata space is
> >> allocated, removing a lot of additional checking and alignment issues.
> >>
> >> However the core issue still persists, the maximum heap size for
> >> compressed oops is calculated wrongly as the NULL page is not properly
> >> accounted for.
> >>
> >> testing:
> >> jprt, jprt test cases
> >>
> >> Thomas
> >>
> >>> Here's a walkthrough of the changes:
> >>>
> >>> As mentioned, the cause of this CR is that ergonomics for determining
> >>> the maximum java heap size usable for compressed oops uses variables
> >>> that are later changed ergonomically.
> >>>
> >>> It is best to look at the changes beginning from
> >>> Arguments::set_ergonomics_flags(): the idea of this change is to avoid
> >>> later overflow, so the change tries to conservatively estimate sizes of
> >>> the non-java heap parts. The complication is that not even the later
> >>> effective alignment of these heap parts has been determined at this
> >>> point.
> >>>
> >>> So the change first calculates the maximum possible heap alignment by
> >>> calling set_max_heap_alignment(); this size is influenced by OS page
> >>> sizes, so the change needs to initialize large pages by calling
> >>> os::large_page_init() in Arguments::parse(), before the call to
> >>> set_ergonomics_flags(). The maximum possible alignment is then
> >>> calculated by asking the active GC for its maximum alignment, as at this
> >>> point the GC has already been determined, the maximum page size, and
> >>> other requirements, like alignment for card table size etc.
> >>>
> >>> Now the code can calculate the conservative estimate for actual maximum
> >>> heap for compressed oops used in set_use_compressed_oops(), by
> >>> subtracting the conservatively aligned sizes of the other heap parts.
> >>> (In Arguments::max_heap_for_compressed_oops()) The result is the maximum
> >>> possible heap that can use compressed oops, minus the aligned metaspace
> >>> size, minus the aligned null page size.
> >>>
> >>> There is another circular dependency problem here, the metaspace size itself is later ergonomically sized; the change fixes this problem by anticipating that in Arguments::max_heap_for_compressed_oops(), using the same predicate for determining whether to ergonomically size it or not [this is CR8009778 I think].
> >>>
> >>> The other changes are straightforward: the os_* changes result from that
> >>> large page initialization must be done earlier now; the changes in the
> >>> collectors themselves are simply about providing the collector's maximum
> >>> alignment. The change in Universe::reserve_heap() contains one assertion that checks whether the conservative estimate for alignment has been conservative enough earlier.
> >>>
> >>> The test case tests test cases from the CR that work now, and additional
> >>> border cases related to ergonomically deciding heap size for compressed
> >>> oops.
> >>>
> >>> One side effect of this change is that the ergonomically determined heap size is slighly smaller now (so that it always fits :).
> >>>
> >>> Thanks,
> >>>    Thomas
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >



From lois.foltan at oracle.com  Fri Aug 30 04:24:10 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 30 Aug 2013 07:24:10 -0400
Subject: RFR JDK-8021954 VM SIGSEGV during classloading on MacOS;
	hs_err_pid file produced
In-Reply-To: <522001DD.8040106@oracle.com>
References: <521BA02E.6080901@oracle.com> <521C11D5.1000409@oracle.com>
	<521C5CEC.90507@oracle.com> <521C8E1D.5030802@oracle.com>
	<521C9F11.5010809@oracle.com> <521D486E.8090207@oracle.com>
	<521E1D0D.80307@oracle.com> <521F2CBF.2090809@oracle.com>
	<521F495C.9030900@oracle.com> <522001DD.8040106@oracle.com>
Message-ID: <522080DA.6080904@oracle.com>


On 8/29/2013 10:22 PM, David Holmes wrote:
> On 29/08/2013 11:15 PM, Lois Foltan wrote:
>>
>> On 8/29/2013 7:13 AM, David Holmes wrote:
>>> On 29/08/2013 1:53 AM, Coleen Phillimore wrote:
>>>> On 8/27/2013 8:46 PM, David Holmes wrote:
>>>>> Thanks for the detailed explanation. It is frustrating that we keep
>>>>> having to revisit these allocation routines.
>>>>>
>>>>> However it still seems to me that we don't need NO_EXCEPT on most of
>>>>> our operator new definitions because they will never return NULL. 
>>>>> This
>>>>> is trivially so for things like:
>>>>>
>>>>>  void* StackObj::operator new(size_t size)     NOEXCEPT {
>>>>> ShouldNotCallThis(); return 0; }
>>>>> void* _ValueObj::operator new(size_t size)    NOEXCEPT {
>>>>> ShouldNotCallThis(); return 0; }
>>>>>
>>>>> but also for anything that invokes vm_exit_out_of_memory directly or
>>>>> indirectly.
>>>>
>>>> I don't think this is a good idea at all.   We want the constructor
>>>> prologue to always check for null before calling the constructor. We
>>>> will never throw C++ exceptions for these so all operator new's are
>>>> NOEXCEPT.   These trivial examples would return zero rather than
>>>> throwing if ShouldNotCallThis() is ifdef'ed out in product. So, this
>>>> example is either trivially wrong without NOEXCEPT or correct without
>>>> NOEXCEPT.   It is safer code to make them all NOEXCEPT.
>>>
>>> If the allocator can never return a NULL value then checking for NULL
>>> is completely redundant.
>> Hi David,
>> We do have allocators that can return a NULL value, like
>> MetaSpace::allocate(), Chunk's operator new(), etc.  Both demonstrating
>> the return of NULL in the two bug reports.
>
> Please re-read what I said. I know we do have allocators that return 
> NULL. We also have allocators that DO NOT return NULL. The NULL check 
> is only needed on the former, not the latter.
Hi David,
Yes, you are correct.  Coleen & I discussed this yesterday and she 
pointed out more of the subtleties behind this.  However, we did go 
forward with the change mainly because of two reasons.  The code's 
user-defined operator new()s do not throw C++ exceptions, this should be 
explicitly stated to all compilers.  Secondly, even in the case of 
allocators that do not return NULL, we have relied on C++ compilers to 
implicitly generate the constructor prologue code to protect against any 
possible situation where they could return NULL.

Thank you for the great discussion on this and your code review,
Lois

>
>>> We don't check our internal allocation routines for NULL returns where
>>> we know they abort on failure, so how is this any different ?
>> Actually we have been checking NULL, it's just that the C++ compiler's
>> have been implicitly checking NULL for us.  Solaris C++ generates by
>> default NULL detection constructor prologue code for user-defined class
>> member operator new() even in a throw situation. For gcc we specify
>> -fcheck-new.  So whether or not we explicitly direct the compiler to
>> check via an empty "throw()" specification or not, it's still being
>> done.  So why should we check now?  Because we have a C++ compiler,
>> clang, that adheres to the standard and doesn't support -fcheck-new.  It
>> wants to be explicitly told.
>
> See above.
>
> Thanks,
> David
> ------
>
>>> AFAICS ShouldNotCallThis() is not ifdef'd out but if it were then yes
>>> this would fail - as would ifdef'ing out a vm_exit_out_of_memory in
>>> the other allocation routines.
>>>> So really the only question is whether NOEXCEPT is better than
>>>> throw().    throw() looks nicer because it's not a macro. NOEXCEPT may
>>>> be required for the future if that's required to conditionally add the
>>>> noexcept keyword.
>>>>
>>>> Maybe we should use throw() for now and worry about the noexcept 
>>>> keyword
>>>> if that becomes an issue.
>>>
>>> It would be less ugly to use throw() but more intrusive in that it
>>> affects all the compilers. Plus I don't know what the benefit would be
>>> of moving from throw() to noexcept if they both mean the same thing?
>> I believe the c++11 standard obsolesces "throw()" in favor of noexcept
>> keyword.  However, I can't imagine that a compiler would completely
>> obsolesce it, I can image there will be a mode to still support 
>> "throw()".
>>
>> Lois
>>>
>>>> David, where are you removing spurious throw() expressions and why?
>>>
>>> ./share/vm/code/nmethod.cpp:void* nmethod::operator new(size_t size,
>>> int nmethod_size) throw () {
>>>
>>> See:
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-August/010526.html 
>>>
>>>
>>>
>>> and subsequent replies. The presence of throw() was considered an
>>> error at the time but now it seems not. I don't know if it has been
>>> removed in hotspot-compiler, or perhaps just in the staging repos for
>>> the ppc64 changes.
>>>
>>> Cheers,
>>> David
>>> ------
>>>
>>>
>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 27/08/2013 10:44 PM, Lois Foltan wrote:
>>>>>>
>>>>>> On 8/27/2013 7:31 AM, David Holmes wrote:
>>>>>>> On 27/08/2013 6:01 PM, Mikael Gerdin wrote:
>>>>>>>> On 2013-08-27 04:41, David Holmes wrote:
>>>>>>>>> On 27/08/2013 4:36 AM, Lois Foltan wrote:
>>>>>>>>>> Please review the following fix:
>>>>>>>>>>
>>>>>>>>>> Internal webrev:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/bug_jdk8021954/
>>>>>>>>>>
>>>>>>>>>> Bug: VM SIGSEGV during classloading on MacOS; hs_err_pid file
>>>>>>>>>> produced &
>>>>>>>>>>           runtime/6878713/Test6878713.sh fails on mac
>>>>>>>>>>
>>>>>>>>>>      bug links at:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8021954
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8022140
>>>>>>>>>>
>>>>>>>>>> Summary of fix:
>>>>>>>>>>      On MacOS, currently Hotspot is built specifying the
>>>>>>>>>> -fcheck-new
>>>>>>>>>> command line option to the llvm-g++ compiler.
>>>>>>>>>>      The -fcheck-new option directs the compiler to "check that
>>>>>>>>>> the
>>>>>>>>>> pointer returned by |operator new| is non-null
>>>>>>>>>>       before attempting to modify the storage allocated." The
>>>>>>>>>> clang++
>>>>>>>>>> compiler does not support the
>>>>>>>>>>       -fcheck-new option.  To obtain similiar functionality when
>>>>>>>>>> building Hotspot with clang++, empty exception
>>>>>>>>>>       throw() specifications must be added to all user-defined
>>>>>>>>>> operator
>>>>>>>>>> new()'s.
>>>>>>>>>
>>>>>>>>> We just spotted something related in the PPC64 port and were 
>>>>>>>>> going
>>>>>>>>> the
>>>>>>>>> other way or removing these "spurious" throw() declarations.
>>>>>>>>>
>>>>>>>>> But this seems really ugly - is there really a need to specialize
>>>>>>>>> this
>>>>>>>>> for clang and use NOEXCEPT to hide it? Shouldn't all C++ 
>>>>>>>>> compilers
>>>>>>>>> honour the nothrow() semantics?
>>>>>>>>>
>>>>>>>>> That said I thought we already handled this using the "const
>>>>>>>>> std::nothrow_t&  nothrow_constant" where needed? Our other
>>>>>>>>> operator new
>>>>>>>>> implementations shouldn't return NULL but will abort.
>>>>>>>>>
>>>>>>>>> So why do we need -fcheck-new or this empty throw() ?
>>>>>>>>
>>>>>>>> I guess that if the C++ compiler knows that operator new() will
>>>>>>>> throw an
>>>>>>>> exception if an allocation fails then it doesn't need to emit
>>>>>>>> code to
>>>>>>>> explicitly avoid calling the constructor.
>>>>>>>
>>>>>>> Yes that is what happens, but why do _we_ need it when ...
>>>>>>>
>>>>>>>> If we declare operator new() with an empty throw() we will also
>>>>>>>> inform
>>>>>>>> the compiler that new can't throw an exception and therefore the
>>>>>>>> compiler needs to explicitly handle failed allocations.
>>>>>>>
>>>>>>> ... we have two kinds of operator new implementations (or at 
>>>>>>> least we
>>>>>>> _should_ only have two kinds):
>>>>>>>
>>>>>>> 1. Will abort on OOM (either ResourceArea exhaustion or Stack
>>>>>>> exhaustion) and so never returns NULL
>>>>>>> 2. Can return NULL and uses std::nothrow to indicate that
>>>>>>>
>>>>>>> So we should not need this if the nothrow is acting as I think it
>>>>>>> should. Have we missed places where nothrow is needed? Do we have
>>>>>>> errant operator new definitions unrelated to the allocation base
>>>>>>> classes?
>>>>>> Hi David,
>>>>>>
>>>>>> I think there may be some confusion about what std::nothrow_t is
>>>>>> actually doing.  It provides a mechanism to overload operator new &
>>>>>> delete in order to direct the compiler to prefer a function 
>>>>>> definition
>>>>>> that also should contain an empty "throw()" specification. Take for
>>>>>> example the standard definition of the global ::operator new(). It
>>>>>> actually looks like:
>>>>>>
>>>>>>   * void * operator new
>>>>>> <a00960.html#a1414bcdb34c39ce82fc84bc8d5287966>
>>>>>>     (std::size_t) throw (std::bad_alloc)
>>>>>>   * void * operator new
>>>>>> <a00960.html#a940b606c7824b4d5dd121199c277d629>
>>>>>>     (std::size_t, const std::nothrow_t &) throw ()
>>>>>>
>>>>>> When the std::nothrow_t parameter is passed to the global ::operator
>>>>>> new() the invoked function is the one that also contains an empty
>>>>>> throw() specification.  It is due to this empty throw() 
>>>>>> specification
>>>>>> that directs or triggers the C++ compiler to generate the 
>>>>>> detection of
>>>>>> NULL constructor prologue.   Specifying only the std::nothrow_t
>>>>>> parameter to a class member user-defined ::operator new() does not
>>>>>> indicate to a C++ compiler that the function does not throw an
>>>>>> exception.  According to the c++98 standard, a function that will
>>>>>> throw
>>>>>> no exceptions should be delcared with an empty "throw()" list
>>>>>> specification.  When first experimenting with a fix, I did just 
>>>>>> try to
>>>>>> overload Hotspot's user-defined operator new() with the 
>>>>>> std:nothrow_t
>>>>>> parameter.  As expected, the mere presence of this parameter did not
>>>>>> trigger the clang++ compiler to generate NULL detection constructor
>>>>>> prologue code.  Unfortunately, probably due to legacy code, some C++
>>>>>> compilers behave differently.  For example, I did confirm with 
>>>>>> Solaris
>>>>>> C++ development, the Solaris C++ by default always generates
>>>>>> constructor
>>>>>> prologue code that detects NULL for class member user-defined 
>>>>>> operator
>>>>>> new() even in a throw situation. G++ provides the -fcheck-new 
>>>>>> command
>>>>>> line option.  It is due to these differences of behavior or 
>>>>>> Hotspot's
>>>>>> build specification of -fcheck-new that has led us to believe that
>>>>>> std::nothrow_t was providing something that it is not.
>>>>>>
>>>>>> That said, I would also prefer what you propose, deciding on two 
>>>>>> kinds
>>>>>> of operator new()'s that can be defined.  I did examine all of the
>>>>>> user-defined operator new()'s within the code and I determined that
>>>>>> only
>>>>>> a very small number possibly could not return NULL. Given this,
>>>>>> factored in with the historical reliance on -fcheck-new for the g++
>>>>>> compilers, I decided the safe route for JDK 8 was to introduce the
>>>>>> NOEXCEPT macro.
>>>>>>
>>>>>> Lois
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> The g++ man page states:
>>>>>>>>
>>>>>>>>         -fcheck-new
>>>>>>>>             Check that the pointer returned by "operator new" is
>>>>>>>> non-null before attempting to modify the storage allocated. This
>>>>>>>> check
>>>>>>>> is normally unnecessary because the C++ standard specifies that
>>>>>>>>             "operator new" will only return 0 if it is declared
>>>>>>>> throw(),
>>>>>>>> in which case the compiler will always check the return value even
>>>>>>>> without this option.  In all other cases, when "operator new"
>>>>>>>>             has a non-empty exception specification, memory
>>>>>>>> exhaustion
>>>>>>>> is signalled by throwing "std::bad_alloc".  See also new 
>>>>>>>> (nothrow).
>>>>>>>>
>>>>>>>> /Mikael
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Tests:
>>>>>>>>>>
>>>>>>>>>>       Solaris: built fastdebug & product images
>>>>>>>>>>       Linux: built fastdebug & product images
>>>>>>>>>>       MacOS:  built fastdebug & product images using llvm-g++ -
>>>>>>>>>> ran
>>>>>>>>>> JTREG
>>>>>>>>>>                      built fastdebug & product images using
>>>>>>>>>> clang++ -
>>>>>>>>>> ran JTREG, JCK vm & lang, vm.quick.testlist (in progress)
>>>>>>>>>>       Windows:  built fastdebug & product images with VS2010
>>>>>>>>>>
>>>>>>
>>>>
>>


From zhengyu.gu at oracle.com  Fri Aug 30 04:38:08 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Fri, 30 Aug 2013 07:38:08 -0400
Subject: RFR: 6991327 : using -Xprof trigger native memory leak
In-Reply-To: <522012A0.4060305@oracle.com>
References: <521F8A72.3080609@oracle.com> <522012A0.4060305@oracle.com>
Message-ID: <52208420.5050308@oracle.com>

Thanks for quick review.

-Zhengyu

On 8/29/2013 11:33 PM, David Holmes wrote:
> Looks okay to me.
>
> Thanks,
> David
>
> On 30/08/2013 3:52 AM, Zhengyu Gu wrote:
>> The is a simple fix for memory leak.
>>
>> FlatProfiler::record_thread_tick allocates array for JavaThread list,
>> but never free it.
>>
>>
>> External bug: http://bugs.sun.com/view_bug.do?bug_id=6991327
>> Internal bug: https://bugs.openjdk.java.net/browse/JDK-6991327
>> Webrev: http://cr.openjdk.java.net/~zgu/6991327/webrev.00/
>> <http://cr.openjdk.java.net/%7Ezgu/6991327/webrev.00/>
>>
>> Test:
>>    Ran test case (2) on bug report with NMT detail tracking on Linux 32,
>> diff report clearly shows memory leak at
>> FlatProfiler::record_thread_tick().  pmap also shows total memory grows
>> continuously.
>>
>>    With the fix, the call site no longer shows on diff report, and there
>> are not obviously memory leaks on the report. pmap shows total memory
>> stops growing after a while.
>>
>> Sanity check:
>>    Passed JPRT with -Xprof flag
>>
>> Thanks,
>>
>> -Zhengyu
>>


From harold.seigel at oracle.com  Fri Aug 30 05:02:30 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 30 Aug 2013 08:02:30 -0400
Subject: RFR S 8023381: VM fails to initialize in
	runtime/CDSCompressedKPtrs/XShareAuto.java
	runtime/SharedArchiveFile/CdsSameObjectAlignment.java
In-Reply-To: <5220025C.5030107@oracle.com>
References: <521F9674.8050703@oracle.com> <5220025C.5030107@oracle.com>
Message-ID: <522089D6.7020506@oracle.com>

Hi David,

Thanks for the review.

Harold

On 8/29/2013 10:24 PM, David Holmes wrote:
> Looks good to me too!
>
> David
>
> On 30/08/2013 4:44 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this small change to fix a problem with some of the JTreg
>> CDS tests.  The fix changes the tests to look for a more generic reason
>> for why the JVM could not use CDS, causing it to exit.  The tests now
>> look for "Unable to use shared archive".  This message is always printed
>> when the JVM exits because it could not use CDS.
>>
>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8023381/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8023381/>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023381
>>
>> The fixed tests were run on Linux 32 and 64 bit, Solaris Sparc 10 and
>> 11, Solaris x86 10, Mac OS X, and Windows.
>>
>> Thanks! Harold
>>


From harold.seigel at oracle.com  Fri Aug 30 05:02:57 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 30 Aug 2013 08:02:57 -0400
Subject: RFR S 8023381: VM fails to initialize in
	runtime/CDSCompressedKPtrs/XShareAuto.java
	runtime/SharedArchiveFile/CdsSameObjectAlignment.java
In-Reply-To: <521FA185.2020304@oracle.com>
References: <521F9674.8050703@oracle.com> <521F9C2F.30504@oracle.com>
	<521FA185.2020304@oracle.com>
Message-ID: <522089F1.4030005@oracle.com>

Hi Misha,

Thanks for the review.

Harold

On 8/29/2013 3:31 PM, Mikhailo Seledtsov wrote:
> Looks good.
>
> Misha
> On 8/29/2013 3:08 PM, Vladimir Kozlov wrote:
>> Looks fine.
>>
>> Vladimir
>>
>> On 8/29/13 11:44 AM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this small change to fix a problem with some of the JTreg
>>> CDS tests.  The fix changes the tests to look for a more generic reason
>>> for why the JVM could not use CDS, causing it to exit.  The tests now
>>> look for "Unable to use shared archive".  This message is always 
>>> printed
>>> when the JVM exits because it could not use CDS.
>>>
>>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8023381/
>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8023381/>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023381
>>>
>>> The fixed tests were run on Linux 32 and 64 bit, Solaris Sparc 10 and
>>> 11, Solaris x86 10, Mac OS X, and Windows.
>>>
>>> Thanks! Harold
>>>
>


From harold.seigel at oracle.com  Fri Aug 30 05:03:18 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 30 Aug 2013 08:03:18 -0400
Subject: RFR S 8023381: VM fails to initialize in
	runtime/CDSCompressedKPtrs/XShareAuto.java
	runtime/SharedArchiveFile/CdsSameObjectAlignment.java
In-Reply-To: <521F9C2F.30504@oracle.com>
References: <521F9674.8050703@oracle.com> <521F9C2F.30504@oracle.com>
Message-ID: <52208A06.50704@oracle.com>

Hi Vladimir,

Thanks for the review.

Harold

On 8/29/2013 3:08 PM, Vladimir Kozlov wrote:
> Looks fine.
>
> Vladimir
>
> On 8/29/13 11:44 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this small change to fix a problem with some of the JTreg
>> CDS tests.  The fix changes the tests to look for a more generic reason
>> for why the JVM could not use CDS, causing it to exit.  The tests now
>> look for "Unable to use shared archive".  This message is always printed
>> when the JVM exits because it could not use CDS.
>>
>> Open webrev at: http://cr.openjdk.java.net/~hseigel/bug_8023381/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8023381/>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023381
>>
>> The fixed tests were run on Linux 32 and 64 bit, Solaris Sparc 10 and
>> 11, Solaris x86 10, Mac OS X, and Windows.
>>
>> Thanks! Harold
>>


From Karen.Kinnear at oracle.com  Fri Aug 30 05:06:38 2013
From: Karen.Kinnear at oracle.com (Karen Kinnear)
Date: Fri, 30 Aug 2013 08:06:38 -0400
Subject: S RFR: Lambda: verification error in generated lambda classes
In-Reply-To: <521FFEC9.5050700@oracle.com>
References: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
	<521E9A45.8040809@oracle.com>
	<491B7272-B309-4193-BF8B-E7889441B6FB@oracle.com>
	<CAFUO74kYcSx5umWA_VY4Aq_R8UnHHcn3VaMsJ-N6qsuNKc4AtQ@mail.gmail.com>
	<8BA6AF53-D39D-4821-8D63-E936FA4592B2@oracle.com>
	<CAFUO74=K1qZF7vu+ewdXcZpKxvbiS47uEHynMbsQX0kkjmutYg@mail.gmail.com>
	<521FFEC9.5050700@oracle.com>
Message-ID: <FA81696D-8873-4679-83C1-409CD8216F92@oracle.com>

Thanks David. I had to also, but this seemed the cleanest approach.

thanks for the review and suggestion,
Karen

On Aug 29, 2013, at 10:09 PM, David Holmes wrote:

> On 30/08/2013 4:02 AM, Keith McGuigan wrote:
>> I think there's an extra set of parenthesis that isn't needed, but other
>> than that, thanks, looks good!
> 
> Agreed on all three counts (extra, not needed, good) :)
> 
> I still had to write out the truth table to be certain :)
> 
> Thanks,
> David
> 
>> 
>> On Thu, Aug 29, 2013 at 1:29 PM, Karen Kinnear <Karen.Kinnear at oracle.com
>> <mailto:Karen.Kinnear at oracle.com>> wrote:
>> 
>>    Keith, David,
>> 
>>    Many thanks for the suggestions. I think Keith's proposal is much
>>    simpler to read. I did
>>    a name change as well to hopefully make this more obvious.
>> 
>>    webrev.02:
>>> 
>>>        >> webrev: http://cr.openjdk.java.net/~acorn/8023872.02/webrev/
>>>        >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>> 
>>    I redid the manual testing, and the longer tests are in progress again.
>> 
>>    thanks,
>>    Karen
>> 
>>    On Aug 28, 2013, at 10:31 PM, Keith McGuigan wrote:
>> 
>>>    I think it's ok as it is, if you need to check it in quick, but I
>>>    agree that this probably should be rewritten better to make the
>>>    logic more obvious.  Maybe separate clauses for reflection/lambda
>>>    code?
>>> 
>>>        ((!is_MAI && !is_MLI) ||
>>>        (is_MAI && VerifyReflectionBytecodes) ||
>>>        (is_MLI && VerifyLambdaBytecodes))
>>> 
>>>    Isn't this equivalent to:
>>>      (!is_MAI || VerifyReflectionBytecodes) &&
>>>      (!is_MLI || VerifyLambdaBytecodes)
>>> 
>>> 
>>> 
>>>    On Wed, Aug 28, 2013 at 8:50 PM, Karen Kinnear
>>>    <Karen.Kinnear at oracle.com <mailto:Karen.Kinnear at oracle.com>> wrote:
>>> 
>>>        Thank you David. I agree, I was tempted to rewrite the entire
>>>        method - in particular, in a debugger
>>>        (so I didn't check the optimized code) we walk the entire &&
>>>        before we make the initial call - in this
>>>        case the initial call would weed out more things faster
>>>        potentially, so ... But I chose not to rewrite since
>>>        they need this quickly and the shaking out would take quite a
>>>        bit longer.
>>> 
>>>        thanks for the review,
>>>        Karen
>>> 
>>>        On Aug 28, 2013, at 8:48 PM, David Holmes wrote:
>>> 
>>>        > Hi Karen,
>>>        >
>>>        > I found the boolean logic very hard to follow there - not
>>>        sure if the refactoring helped or hindered :)
>>>        >
>>>        > But it looks okay.
>>>        >
>>>        > David
>>>        >
>>>        > On 29/08/2013 5:42 AM, Karen Kinnear wrote:
>>>        >> Please review - lambda team needs this change to get in by
>>>        tomorrow so
>>>        >> they can push
>>>        >> the (8010433) metafactory change which is waiting on the
>>>        vm. Thanks.
>>>        >>
>>>        >>
>>>        >> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
>>>        >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>>>        >>
>>>        >> Testing:
>>>        >> The failure comes if you apply an early patch of 8010433 to
>>>        the jdk and
>>>        >> do not
>>>        >> make the vm change. So testing included 4 binaries: master,
>>>        newjdk,
>>>        >> newvm, newjdkvm
>>>        >>
>>>        >> jtreg for SpinedBufferTest with various flags - these are
>>>        the expected
>>>        >> results below
>>>        >> The key point is newjdk -Xverify: all fails
>>>        >> newjdkvm -Xverify:all passes, but if you also turn on
>>>        >> -XX:+VerifyLambdaBytecodes you see
>>>        >>    the verification error
>>>        >>
>>>        >> 1. master
>>>        >>  no flags: timed out
>>>        >>  -Xverify:all: timed out
>>>        >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>>        >>
>>>        >> 2. newjdk
>>>        >>  no flags: timed out
>>>        >>  -Xverify:all
>>>        >>    java.lang.BootstrapMethodError: call site initialization
>>>        exception
>>>        >> ... cause:
>>>        >>      VerifyError: Bad invokespecial instruction: current
>>>        class isn't
>>>        >> assignable to reference class
>>>        >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>>        >>
>>>        >> 3. newvm
>>>        >>   no flags: timed out
>>>        >>   rerun.sh: -Xverify:all: passed
>>>        >>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>>        >>   -XX:+VerifyLambdaBytecodes: passed, didn't try verification
>>>        >>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
>>>        >>
>>>        >> 4. newjdkvm
>>>        >>  rerun.sh: no flags: passed
>>>        >> rerun.verify.sh <http://rerun.verify.sh/>: -Xverify:all: passed
>>>        >>  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
>>>        >>    Verification for
>>>        java.util.streamIntPipeline$7$1$$Lambda$9 failed
>>>        >>
>>>        >> regression testing:
>>>        >> newvm:
>>>        >>   vm.quick.testlist - in progress
>>>        >>   jtreg java/util/stream - in progress
>>>        >>   jprt -stree . - in progress
>>>        >>
>>>        >> newvmjdk (Brian testing in lambda repo) - in progress
>>>        >>
>>>        >> thanks,
>>>        >> Karen
>>>        >>
>>> 
>>> 
>>> 
>>> 
>>>    --
>>>    - Keith McGuigan <keith.mcguigan at alumni.unh.edu
>>>    <mailto:keith.mcguigan at alumni.unh.edu>>
>> 
>> 
>> 
>> 
>> --
>> - Keith McGuigan <keith.mcguigan at alumni.unh.edu
>> <mailto:keith.mcguigan at alumni.unh.edu>>


From Karen.Kinnear at oracle.com  Fri Aug 30 05:09:43 2013
From: Karen.Kinnear at oracle.com (Karen Kinnear)
Date: Fri, 30 Aug 2013 08:09:43 -0400
Subject: S RFR: Lambda: verification error in generated lambda classes
In-Reply-To: <CAFUO74kJ-0Qrztpou99dSUpcym-7S2x6=VjV=ONZxUSMuH5jZQ@mail.gmail.com>
References: <4AA4F702-F468-4FC2-A71F-A3EF7B86A4AE@oracle.com>
	<521E9A45.8040809@oracle.com>
	<491B7272-B309-4193-BF8B-E7889441B6FB@oracle.com>
	<CAFUO74kYcSx5umWA_VY4Aq_R8UnHHcn3VaMsJ-N6qsuNKc4AtQ@mail.gmail.com>
	<8BA6AF53-D39D-4821-8D63-E936FA4592B2@oracle.com>
	<CAFUO74kJ-0Qrztpou99dSUpcym-7S2x6=VjV=ONZxUSMuH5jZQ@mail.gmail.com>
Message-ID: <803A430B-FE4F-468E-A169-C0DDEFD5CD06@oracle.com>

Thanks Keith - I'll remove them. Thanks for the suggestion and the review,
Karen

On Aug 29, 2013, at 2:31 PM, Keith McGuigan wrote:

> I think there's an extra set of parenthesis that isn't needed, but other than that, thanks, looks good!
> 
> 
> On Thu, Aug 29, 2013 at 1:29 PM, Karen Kinnear <Karen.Kinnear at oracle.com> wrote:
> Keith, David,
> 
> Many thanks for the suggestions. I think Keith's proposal is much simpler to read. I did
> a name change as well to hopefully make this more obvious.
> 
> webrev.02: 
>> >> webrev: http://cr.openjdk.java.net/~acorn/8023872.02/webrev/
>> >> http://bugs.sun.com/view_bug.do?bug_id=8023872
> 
> I redid the manual testing, and the longer tests are in progress again.
> 
> thanks,
> Karen
> 
> On Aug 28, 2013, at 10:31 PM, Keith McGuigan wrote:
> 
>> I think it's ok as it is, if you need to check it in quick, but I agree that this probably should be rewritten better to make the logic more obvious.  Maybe separate clauses for reflection/lambda code?
>> 
>>     ((!is_MAI && !is_MLI) ||
>>     (is_MAI && VerifyReflectionBytecodes) ||
>>     (is_MLI && VerifyLambdaBytecodes)) 
>> 
>> Isn't this equivalent to:
>>   (!is_MAI || VerifyReflectionBytecodes) &&
>>   (!is_MLI || VerifyLambdaBytecodes)
>> 
>> 
>> 
>> On Wed, Aug 28, 2013 at 8:50 PM, Karen Kinnear <Karen.Kinnear at oracle.com> wrote:
>> Thank you David. I agree, I was tempted to rewrite the entire method - in particular, in a debugger
>> (so I didn't check the optimized code) we walk the entire && before we make the initial call - in this
>> case the initial call would weed out more things faster potentially, so ... But I chose not to rewrite since
>> they need this quickly and the shaking out would take quite a bit longer.
>> 
>> thanks for the review,
>> Karen
>> 
>> On Aug 28, 2013, at 8:48 PM, David Holmes wrote:
>> 
>> > Hi Karen,
>> >
>> > I found the boolean logic very hard to follow there - not sure if the refactoring helped or hindered :)
>> >
>> > But it looks okay.
>> >
>> > David
>> >
>> > On 29/08/2013 5:42 AM, Karen Kinnear wrote:
>> >> Please review - lambda team needs this change to get in by tomorrow so
>> >> they can push
>> >> the (8010433) metafactory change which is waiting on the vm. Thanks.
>> >>
>> >>
>> >> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
>> >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>> >>
>> >> Testing:
>> >> The failure comes if you apply an early patch of 8010433 to the jdk and
>> >> do not
>> >> make the vm change. So testing included 4 binaries: master, newjdk,
>> >> newvm, newjdkvm
>> >>
>> >> jtreg for SpinedBufferTest with various flags - these are the expected
>> >> results below
>> >> The key point is newjdk -Xverify: all fails
>> >> newjdkvm -Xverify:all passes, but if you also turn on
>> >> -XX:+VerifyLambdaBytecodes you see
>> >>    the verification error
>> >>
>> >> 1. master
>> >>  no flags: timed out
>> >>  -Xverify:all: timed out
>> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> >>
>> >> 2. newjdk
>> >>  no flags: timed out
>> >>  -Xverify:all
>> >>    java.lang.BootstrapMethodError: call site initialization exception
>> >> ... cause:
>> >>      VerifyError: Bad invokespecial instruction: current class isn't
>> >> assignable to reference class
>> >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> >>
>> >> 3. newvm
>> >>   no flags: timed out
>> >>   rerun.sh: -Xverify:all: passed
>> >>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>> >>   -XX:+VerifyLambdaBytecodes: passed, didn't try verification
>> >>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
>> >>
>> >> 4. newjdkvm
>> >>  rerun.sh: no flags: passed
>> >>  rerun.verify.sh: -Xverify:all: passed
>> >>  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
>> >>    Verification for java.util.streamIntPipeline$7$1$$Lambda$9 failed
>> >>
>> >> regression testing:
>> >> newvm:
>> >>   vm.quick.testlist - in progress
>> >>   jtreg java/util/stream - in progress
>> >>   jprt -stree . - in progress
>> >>
>> >> newvmjdk (Brian testing in lambda repo) - in progress
>> >>
>> >> thanks,
>> >> Karen
>> >>
>> 
>> 
>> 
>> 
>> -- 
>> - Keith McGuigan <keith.mcguigan at alumni.unh.edu>
> 
> 
> 
> 
> -- 
> - Keith McGuigan <keith.mcguigan at alumni.unh.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130830/fccf298b/attachment-0001.html 

From zhengyu.gu at oracle.com  Fri Aug 30 05:28:38 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Fri, 30 Aug 2013 08:28:38 -0400
Subject: RFR (S) 8022335 - (round 2) Native stack walk on Windows x64
In-Reply-To: <521FCD16.10600@oracle.com>
References: <521FCD16.10600@oracle.com>
Message-ID: <52208FF6.3020008@oracle.com>

Hi Ioi,

src/os_cpu/windows_x86/vm/os_windows_x86.cpp

493   if (fp == NULL) {
494     return frame();
495   }

probably you want to move it outside #ifdef AMD64. It is not platform 
specific, right?

Other than that, looks good to me.

FYI:
   You can use "CrashGCForDumpingJavaThread" flag to cause JVM to crash.

Thanks,

-Zhengyu




On 8/29/2013 6:37 PM, Ioi Lam wrote:
> Please review this fix:
>
> http://cr.openjdk.java.net/~iklam/8022335/win64_stack_walk_002/
>
> Bug: Native stack walk while generating hs_err does not work on 
> Windows x64
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022335
>     https://bugs.openjdk.java.net/browse/JDK-8022335
>
> What's new:
>
>     The code is much more simplified than my last version. All 
> interesting
>     code is in a single function -- os::platform_print_native_stack
>     in os_windows_x86.cpp. The rest is just busy work.
>
> Summary of fix:
>
>     Windows x64 binaries are built (unconditionally) with the 
> equivalent of
>     -fomit-frame-pointer, so HotSpot's build-in native stack walking code
>     will fail to find the sender frame. As a result, hs_err on 
> Windows/x64
>     will always list a single frame.
>
>     I have added the os::platform_print_native_stack() function for
>     Windows/x64 only. It uses the StackWalk64 API to walk the stace.
>
>     Because the Win/x64 frame layout is very different than what 
> HotSpot expects,
>     I decided to implement os::platform_print_native_stack() as a 
> completely
>     stand-alone function, and do not interact with the existing 
> "frame" C++ class.
>     See comments in os_windows_x86.cpp for details.
>
> Deficiency of fix:
>
>     StackWalk64 knows nothing about the Java frames. So hs_err will 
> display only
>     the native frames, and stop as soon as the first Java frame is 
> reached. It will
>     also NOT display any native frames below Java frames.
>
>     Printing the Java frames *may* be possible. However, at this 
> point, I want
>     to keep the code simple and crash proof. I will file a different 
> bug for
>     printing the Java frames.
>
> Bonus:
>
>     As a side-fix, I refactored a bunch of duplicated code in 
> decoder.cpp into
>     the DecoderLocker class.
>
> Tests:
>
>     JPRT
>     UTE (vm.runtime.testlist, vm.quick.testlist, 
> vm.parallel_class_loading.testlist)
>
>     I also manually inserted some crashes into jvm.dll and verified 
> that the
>     native stack trace is printed as expected on Win/x64.
>
>
> Thanks
> - Ioi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130830/f85b186a/attachment.html 

From lois.foltan at oracle.com  Fri Aug 30 06:36:14 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 30 Aug 2013 09:36:14 -0400
Subject: RFR JDK-8022407 (round 2) sun/misc/CopyMemory.java fails with
	SIGSEGV in Unsafe_SetByte+0x35
In-Reply-To: <52200110.7030400@oracle.com>
References: <521CD14D.5040809@oracle.com> <521E39DB.1050901@oracle.com>
	<521F2D7F.5030001@oracle.com> <521F381B.5090005@oracle.com>
	<52200110.7030400@oracle.com>
Message-ID: <52209FCE.6000005@oracle.com>


On 8/29/2013 10:18 PM, David Holmes wrote:
> On 29/08/2013 10:01 PM, Lois Foltan wrote:
>>
>> On 8/29/2013 7:16 AM, David Holmes wrote:
>>> Hi Lois,
>>>
>>> Is this still needed:
>>>
>>>  142     PCH_FLAG/unsafe.o = $(PCH_FLAG/NO_PCH)
>>>
>>> given you no longer use -O0 ?
>> Hi David,
>> Yes, I believe so but this might be a cautionary change on my part. I
>> read the comment to imply that Clang does not support a precompiled
>> header compiled with an optimization level that is different than the
>> one used to compile the actual C++ file, this is why I chose to add
>> unsafe.o.
>
> I read the comment as only applying to a combination of -O0 with -O3. 
> So now the comment is inaccurate as it claims all files are compiled 
> with -O0.
>
> 133     # There are some files which don't like precompiled headers
> 134     # The following files are build with 'OPT_CFLAGS/NOOPT' (-O0) 
> in the opt build.
> 135     # But Clang doesn't support a precompiled header which was 
> compiled with -O3
> 136     # to be used in a compilation unit which uses '-O0'. We could 
> also prepare an
> 137     # extra '-O0' PCH file for the opt build and use it here, but 
> it's probably
> 138     # not worth the effort as long as only two files need this 
> special handling.
>
> Either the comment or the entry at line 142 need to be changed. (the 
> part about 'two files' is already out of date :( )

Hi David,
Line #142 is necessary.  If clang++ compiles unsafe.o with -O1 and tries 
to include the precompiled header that is compiled by default with -Os, 
(note that -Os is the current default, not -O3 as the comment 
indicates), the following compile time error is generated:

     error: __OPTIMIZE_SIZE__ predefined macro was enabled in PCH file 
but is currently disabled

So, the the comment is incorrect in many ways.  I have entered 
https://bugs.openjdk.java.net/browse/JDK-8024050, detailing the issues.

Thanks,
Lois

>
> David
> -----
>
>> Lois
>>
>>> Thanks,
>>> David
>>>
>>> On 29/08/2013 3:56 AM, Lois Foltan wrote:
>>>>
>>>> Please review the updated webrev:
>>>>      open webrev at
>>>> http://cr.openjdk.java.net/~hseigel/bug_jdk8022407.2/
>>>>
>>>> Bug:
>>>>      bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>>>
>>>> Summary of fix:
>>>>
>>>>      The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++
>>>> compiler, exhibited a compiler
>>>>      optimization issue when prims/unsafe.cpp was compiled at the
>>>> default -Os level. As a work around
>>>>      fix, knock the optimization level down down to -O1.
>>>>
>>>> Tests: MacOS: built fastdebug & product images using clang++ (ran 
>>>> JTREG
>>>> & vm.quick.testlist)
>>>>            built using llvm-g++ to verifyprims/unsafe.cpp remained
>>>> compiled at -Os
>>>>
>>>> Thank you, Lois
>>>>
>>>>
>>


From alejandro.murillo at oracle.com  Fri Aug 30 06:42:49 2013
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 30 Aug 2013 13:42:49 +0000
Subject: hg: hsx/hotspot-emb/hotspot: 27 new changesets
Message-ID: <20130830134405.C648F6241C@hg.openjdk.java.net>

Changeset: b649cfa58604
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b649cfa58604

Added tag jdk8-b105 for changeset acac3bde66b2

! .hgtags

Changeset: c6ec0a97b30a
Author:    sla
Date:      2013-08-21 13:18 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c6ec0a97b30a

8022808: Kitchensink hangs on macos
Summary: Use pthread_mach_thread_np() instead of mach_thread_self() to avoid leaking resources
Reviewed-by: dholmes, rbackman

! src/os/bsd/vm/os_bsd.cpp

Changeset: 3a57fa7a4cd0
Author:    hseigel
Date:      2013-08-22 11:52 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/3a57fa7a4cd0

7121403: [TESTBUG] runtime/7051189/Xchecksig.sh fails on 64bit solaris
8023393: Need to suppress info message if -Xcheck:jni used with libjsig.dylab on Mac OSX
Summary: Rewrite 7051189 test in Java, port Linux fix for 7051189 to Mac OSX.
Reviewed-by: coleenp, dholmes, mseledtsov, ccheung

! src/os/bsd/vm/os_bsd.cpp
- test/runtime/7051189/Xchecksig.sh
+ test/runtime/XCheckJniJsig/XCheckJSig.java

Changeset: e37ab280bbce
Author:    allwin
Date:      2013-07-23 14:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e37ab280bbce

8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__"
Reviewed-by: sla, sundar, kmo
Contributed-by: yunda.mly at taobao.com

! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js

Changeset: 669d9a235486
Author:    sla
Date:      2013-08-22 14:56 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/669d9a235486

Merge


Changeset: c062a6e1fa33
Author:    iklam
Date:      2013-08-22 10:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c062a6e1fa33

8023406: make/windows/build_vm_def.sh takes too long even when BUILD_WIN_SA != 1
Summary: Avoid dumping C++ vtable when BUILD_WIN_SA != 1
Reviewed-by: dcubed, sla, tbell

! make/windows/build_vm_def.sh
! make/windows/makefiles/debug.make
! make/windows/makefiles/fastdebug.make
! make/windows/makefiles/product.make
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/vm.make

Changeset: 811aea34d5e7
Author:    iklam
Date:      2013-08-22 13:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/811aea34d5e7

Merge


Changeset: ff2520b97b00
Author:    jiangli
Date:      2013-08-22 19:27 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ff2520b97b00

8023547: com/sun/jdi/RedefineMulti.sh fails with IllegalArgumentException after JDK-8021948 .
Summary: Need to check if the constant pool mapping returns 0.
Reviewed-by: coleenp, sspitsyn

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 887db75613f8
Author:    jiangli
Date:      2013-08-22 17:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/887db75613f8

Merge


Changeset: a70566600baf
Author:    poonam
Date:      2013-08-21 22:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a70566600baf

8020530: Non heap memory size calculated incorrectly
Reviewed-by: coleenp, sla
Contributed-by: vladimir.kempik at oracle.com

! src/share/vm/services/management.cpp

Changeset: 730210728146
Author:    poonam
Date:      2013-08-22 18:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/730210728146

Merge

- test/runtime/7051189/Xchecksig.sh

Changeset: 817e46dd5864
Author:    poonam
Date:      2013-08-22 21:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/817e46dd5864

Merge


Changeset: 739c309fd729
Author:    mgronlun
Date:      2013-08-23 10:36 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/739c309fd729

8023457: Event based tracing framework needs a mutex for thread groups
Reviewed-by: acorn, sla

! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp

Changeset: cacc421f39d7
Author:    dcubed
Date:      2013-08-23 10:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cacc421f39d7

Merge

- test/runtime/7051189/Xchecksig.sh

Changeset: badf4244ceae
Author:    hseigel
Date:      2013-08-25 21:21 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/badf4244ceae

8022183: GCC 4.6 change sdefault setting for omit-frame-pointer which breaks hotspot stack walking
Summary: Explicitly specify -fno-omit-frame-pointer.
Reviewed-by: coleenp, dholmes, dcubed

! make/linux/makefiles/amd64.make
! make/linux/makefiles/gcc.make

Changeset: faf2631b9334
Author:    dsimms
Date:      2013-08-26 09:33 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/faf2631b9334

8022683: JNI GetStringUTFChars should return NULL on allocation failure not abort the VM
Summary: Return NULL on OOM from GetStringChars, GetStringUTFChars and Get<PrimitiveType>ArrayElements family of functions.
Reviewed-by: dholmes, coleenp

! src/share/vm/memory/allocation.hpp
! src/share/vm/prims/jni.cpp

Changeset: 4c84d351cca9
Author:    stefank
Date:      2013-08-16 13:22 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4c84d351cca9

8007074: SIGSEGV at ParMarkBitMap::verify_clear()
Summary: Replace the broken large pages implementation on Linux. New flag: -XX:+UseTransparentHugePages - Linux specific flag to turn on transparent huge page hinting with madvise(..., MAP_HUGETLB). Changed behavior: -XX:+UseLargePages - tries to use -XX:+UseTransparentHugePages before trying other large pages implementations (on Linux). Changed behavior: -XX:+UseHugeTLBFS - Use upfront allocation of Large Pages instead of using the broken implementation to dynamically committing large pages. Changed behavior: -XX:LargePageSizeInBytes - Turned off the ability to use this flag on Linux and provides warning to user if set to a value different than the OS chosen large page size. Changed behavior: Setting no large page size - Now defaults to use -XX:UseTransparentHugePages if the OS supports it. Previously, -XX:+UseHugeTLBFS was chosen if the OS was configured to use large pages.
Reviewed-by: tschatzl, dcubed, brutisso

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/globals_linux.hpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp
! src/share/vm/services/memTracker.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 21ffbaa691b5
Author:    stefank
Date:      2013-08-26 07:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/21ffbaa691b5

Merge

! src/share/vm/prims/jni.cpp

Changeset: 1bb10d3170fa
Author:    jmasa
Date:      2013-08-16 06:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1bb10d3170fa

8022817: CMS should not shrink if compaction was not done
Reviewed-by: ysr, mgerdin

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: f7d3b4387a16
Author:    brutisso
Date:      2013-08-21 22:35 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f7d3b4387a16

8022872: G1: Use correct GC cause for young GC triggered by humongous allocations
Reviewed-by: tonyp, tschatzl

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp

Changeset: c31eb8c86a50
Author:    brutisso
Date:      2013-08-22 04:14 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c31eb8c86a50

Merge


Changeset: ec145d04eda8
Author:    jmasa
Date:      2013-08-23 15:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ec145d04eda8

Merge


Changeset: 1624a68007bd
Author:    jmasa
Date:      2013-08-27 18:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1624a68007bd

Merge

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 62f527c674d2
Author:    dholmes
Date:      2013-08-29 00:22 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/62f527c674d2

Merge

! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp

Changeset: 18b4798adbc4
Author:    amurillo
Date:      2013-08-30 00:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/18b4798adbc4

Merge

- test/runtime/7051189/Xchecksig.sh

Changeset: aed585cafc0d
Author:    amurillo
Date:      2013-08-30 00:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/aed585cafc0d

Added tag hs25-b48 for changeset 18b4798adbc4

! .hgtags

Changeset: c169f7038414
Author:    amurillo
Date:      2013-08-30 00:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c169f7038414

8024022: new hotspot build - hs25-b49
Reviewed-by: jcoomes

! make/hotspot_version


From volker.simonis at gmail.com  Fri Aug 30 07:32:27 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 30 Aug 2013 16:32:27 +0200
Subject: RFR (S) 8022335 - (round 2) Native stack walk on Windows x64
In-Reply-To: <521FCD16.10600@oracle.com>
References: <521FCD16.10600@oracle.com>
Message-ID: <CA+3eh11Bfy0kN4tfN-f5DYa5=7CrbLC_vjdSbFnsr_xFRfE_yQ@mail.gmail.com>

On Fri, Aug 30, 2013 at 12:37 AM, Ioi Lam <ioi.lam at oracle.com> wrote:
> Please review this fix:
>
> http://cr.openjdk.java.net/~iklam/8022335/win64_stack_walk_002/
>
> Bug: Native stack walk while generating hs_err does not work on Windows
x64
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022335
>     https://bugs.openjdk.java.net/browse/JDK-8022335
>
> What's new:
>
>     The code is much more simplified than my last version. All interesting
>     code is in a single function -- os::platform_print_native_stack
>     in os_windows_x86.cpp. The rest is just busy work.
>
> Summary of fix:
>
>     Windows x64 binaries are built (unconditionally) with the equivalent
of
>     -fomit-frame-pointer,

Why do you think so? If I'm looking at the build logs and
make/windows/makefiles/compile.make I see that we always compile with '/O2
/Oy-' which according to
http://msdn.microsoft.com/en-us/library/2kxx5t2c%28v=vs.100%29.aspx means
'disable frame-pointer omission'. So according to that documentation, we
should have frame pointers in all functions.

Actually '/Oy-' was introduced in order to get better native stack traces
with http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6655385
Doesn?t it help or are there any other additional problem?

Currently I get the following in the hs_err file on Windows for a Java
program which crashes in Unsafe:

# JRE version: OpenJDK Runtime Environment (8.0) (build
1.8.0-internal-fastdebug-_2013_08_29_21_12-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b45-fastdebug mixed mode
windows-amd64 compressed oops)
# Problematic frame:
# V  [jvm.dll+0x28c7a7]
...
*Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [jvm.dll+0x28c7a7]
J  Crash.crashIt(Lsun/misc/Unsafe;I)V @ 0x0000000008e9b19c
[0x0000000008e9b140+92]
v  ~StubRoutines::call_stub
V  [jvm.dll+0x2c961a]
*
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.misc.Unsafe.putAddress(JJ)V+0
J  Crash.crashIt(Lsun/misc/Unsafe;I)V @ 0x0000000008e9b19c
[0x0000000008e9b140+92]
j  Crash.doIt()V+45
v  ~StubRoutines::call_stub
j
 sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j
 sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j
 sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j
 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+56
j  Crash.main([Ljava/lang/String;)V+32
v  ~StubRoutines::call_stub


On Linux, the same crashing program produces the following output in the
hs_err file:

# JRE version: OpenJDK Runtime Environment (8.0) (build
1.8.0-internal-jvmtests_2013_08_29_20_14-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b45 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# V  [libjvm.so+0x9b4ba7]  Unsafe_SetNativeAddress+0xa7
...
*Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x9b4ba7]  Unsafe_SetNativeAddress+0xa7
j  sun.misc.Unsafe.putAddress(JJ)V+0
J  Crash.crashIt(Lsun/misc/Unsafe;I)V @ 0x00007f0b4d0f2c9c
[0x00007f0b4d0f2b80+284]
v  ~StubRoutines::call_stub
V  [libjvm.so+0x6174ee]  JavaCalls::call_helper(JavaValue*, methodHandle*,
JavaCallArguments*, Thread*)+0x104e
V  [libjvm.so+0x8c2e12]  Reflection::invoke(instanceKlassHandle,
methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle,
bool, Thread*)+0x5e2
V  [libjvm.so+0x8c63e7]  Reflection::invoke_method(oopDesc*, Handle,
objArrayHandle, Thread*)+0x147
V  [libjvm.so+0x66dd8e]  JVM_InvokeMethod+0x25e
j
 sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j
 sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j
 sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j
 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+56
j  Crash.main([Ljava/lang/String;)V+32
v  ~StubRoutines::call_stub
V  [libjvm.so+0x6174ee]  JavaCalls::call_helper(JavaValue*, methodHandle*,
JavaCallArguments*, Thread*)+0x104e
V  [libjvm.so+0x631226]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*,
JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x346
V  [libjvm.so+0x63b98a]  jni_CallStaticVoidMethod+0x17a
C  [libjli.so+0x75ed]  JavaMain+0x83d*

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.misc.Unsafe.putAddress(JJ)V+0
J  Crash.crashIt(Lsun/misc/Unsafe;I)V @ 0x00007f0b4d0f2c9c
[0x00007f0b4d0f2b80+284]
j  Crash.doIt()V+45
v  ~StubRoutines::call_stub
j
 sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j
 sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j
 sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j
 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+56
j  Crash.main([Ljava/lang/String;)V+32
v  ~StubRoutines::call_stub

So while the native (i.e. "mixed") stack trace is still much more accurate
on Linux, it isn't just a single line as you wrote. Maybe we could work on
improving this situation on Windows without a separate Windows stack
tracing routine or are there any fundamental problems which prevent this?

>     so HotSpot's build-in native stack walking code
>     will fail to find the sender frame. As a result, hs_err on Windows/x64
>     will always list a single frame.
>
>     I have added the os::platform_print_native_stack() function for
>     Windows/x64 only. It uses the StackWalk64 API to walk the stace.
>
>     Because the Win/x64 frame layout is very different than what HotSpot
> expects,
>     I decided to implement os::platform_print_native_stack() as a
completely
>     stand-alone function, and do not interact with the existing "frame"
C++
> class.
>     See comments in os_windows_x86.cpp for details.
>
> Deficiency of fix:
>
>     StackWalk64 knows nothing about the Java frames. So hs_err will
display
> only
>     the native frames, and stop as soon as the first Java frame is
reached.
> It will
>     also NOT display any native frames below Java frames.
>
>     Printing the Java frames *may* be possible. However, at this point, I
> want
>     to keep the code simple and crash proof. I will file a different bug
for
>     printing the Java frames.
>
> Bonus:
>
>     As a side-fix, I refactored a bunch of duplicated code in decoder.cpp
> into
>     the DecoderLocker class.
>

I would really appreciate if you could do this in a separate change. I
think it is commonly agreed upon that "small unrelated fixes" (like
comments, white-space changes or single line fixes) may go into another
change but these changes are in IMHO big enough to justify a different bug
ID and change set.

> Tests:
>
>     JPRT
>     UTE (vm.runtime.testlist, vm.quick.testlist,
> vm.parallel_class_loading.testlist)
>
>     I also manually inserted some crashes into jvm.dll and verified that
the
>     native stack trace is printed as expected on Win/x64.
>

Maybe you can use/extend the WhiteBox API to write some good tests?

>
> Thanks
> - Ioi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130830/26fbf9b8/attachment-0001.html 

From calvin.cheung at oracle.com  Fri Aug 30 08:56:24 2013
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 30 Aug 2013 08:56:24 -0700
Subject: RFR: 6991327 : using -Xprof trigger native memory leak
In-Reply-To: <521F8A72.3080609@oracle.com>
References: <521F8A72.3080609@oracle.com>
Message-ID: <5220C0A8.3000407@oracle.com>

It looks good to me.

Calvin
On 8/29/2013 10:52 AM, Zhengyu Gu wrote:
> The is a simple fix for memory leak.
>
> FlatProfiler::record_thread_tick allocates array for JavaThread list, 
> but never free it.
>
>
> External bug: http://bugs.sun.com/view_bug.do?bug_id=6991327
> Internal bug: https://bugs.openjdk.java.net/browse/JDK-6991327
> Webrev: http://cr.openjdk.java.net/~zgu/6991327/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ezgu/6991327/webrev.00/>
>
> Test:
>   Ran test case (2) on bug report with NMT detail tracking on Linux 
> 32, diff report clearly shows memory leak at 
> FlatProfiler::record_thread_tick().  pmap also shows total memory 
> grows continuously.
>
>   With the fix, the call site no longer shows on diff report, and 
> there are not obviously memory leaks on the report. pmap shows total 
> memory stops growing after a while.
>
> Sanity check:
>   Passed JPRT with -Xprof flag
>
> Thanks,
>
> -Zhengyu
>


From zhengyu.gu at oracle.com  Fri Aug 30 09:10:42 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Fri, 30 Aug 2013 12:10:42 -0400
Subject: RFR: 6991327 : using -Xprof trigger native memory leak
In-Reply-To: <5220C0A8.3000407@oracle.com>
References: <521F8A72.3080609@oracle.com> <5220C0A8.3000407@oracle.com>
Message-ID: <5220C402.5070707@oracle.com>

Thanks for the review.

-Zhengyu

On 8/30/2013 11:56 AM, Calvin Cheung wrote:
> It looks good to me.
>
> Calvin
> On 8/29/2013 10:52 AM, Zhengyu Gu wrote:
>> The is a simple fix for memory leak.
>>
>> FlatProfiler::record_thread_tick allocates array for JavaThread list, 
>> but never free it.
>>
>>
>> External bug: http://bugs.sun.com/view_bug.do?bug_id=6991327
>> Internal bug: https://bugs.openjdk.java.net/browse/JDK-6991327
>> Webrev: http://cr.openjdk.java.net/~zgu/6991327/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Ezgu/6991327/webrev.00/>
>>
>> Test:
>>   Ran test case (2) on bug report with NMT detail tracking on Linux 
>> 32, diff report clearly shows memory leak at 
>> FlatProfiler::record_thread_tick().  pmap also shows total memory 
>> grows continuously.
>>
>>   With the fix, the call site no longer shows on diff report, and 
>> there are not obviously memory leaks on the report. pmap shows total 
>> memory stops growing after a while.
>>
>> Sanity check:
>>   Passed JPRT with -Xprof flag
>>
>> Thanks,
>>
>> -Zhengyu
>>
>


From lois.foltan at oracle.com  Fri Aug 30 10:18:11 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 30 Aug 2013 13:18:11 -0400
Subject: S RFR JDK-8024050: Incorrect optimization level and comment specified
	for unsafe.cpp
In-Reply-To: <5220C53F.8020705@oracle.com>
References: <5220C53F.8020705@oracle.com>
Message-ID: <5220D3D3.3090802@oracle.com>


Please review the following fix:
     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8024050/

Bug: bug link at https://bugs.openjdk.java.net/browse/JDK-8024050

Summary of fix:

     The original sources used for the JDK-8022407 webrev sponsorship 
contained an incorrect optimization
     level specification for unsafe.cpp that was fixed on the MacOS 
machine prior to testing.  Unfortunately,
     this incorrect specification of -01 instead of -O1 was committed.  
In addition, corrected the comment for
     the Clang optimization level skew issue between PCH Files and files 
of different optimization levels.

Tests:
     MacOS: built fastdebug & product images using clang++ and llvm-g++ 
Ran original JDK-8022407 test case.
                   JTREG testing in progress.

Thank you,
Lois



From ron.durbin at oracle.com  Fri Aug 30 10:28:37 2013
From: ron.durbin at oracle.com (Ron Durbin)
Date: Fri, 30 Aug 2013 10:28:37 -0700 (PDT)
Subject: S RFR JDK-8024050: Incorrect optimization level and comment
	specified for unsafe.cpp
In-Reply-To: <5220D3D3.3090802@oracle.com>
References: <5220C53F.8020705@oracle.com> <5220D3D3.3090802@oracle.com>
Message-ID: <f573f887-e8ee-4a36-8564-028f4a9a0137@default>

Lois I am unofficial reviewer, but the change looks good.

Ron

> -----Original Message-----
> From: Lois Foltan
> Sent: Friday, August 30, 2013 11:18 AM
> To: hotspot-runtime-dev at openjdk.java.net; build-dev at openjdk.java.net
> Subject: S RFR JDK-8024050: Incorrect optimization level and comment specified for
> unsafe.cpp
> 
> 
> Please review the following fix:
>      open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8024050/
> 
> Bug: bug link at https://bugs.openjdk.java.net/browse/JDK-8024050
> 
> Summary of fix:
> 
>      The original sources used for the JDK-8022407 webrev sponsorship contained an incorrect
> optimization
>      level specification for unsafe.cpp that was fixed on the MacOS machine prior to
> testing.  Unfortunately,
>      this incorrect specification of -01 instead of -O1 was committed.
> In addition, corrected the comment for
>      the Clang optimization level skew issue between PCH Files and files of different
> optimization levels.
> 
> Tests:
>      MacOS: built fastdebug & product images using clang++ and llvm-g++ Ran original JDK-
> 8022407 test case.
>                    JTREG testing in progress.
> 
> Thank you,
> Lois
> 
> 

From daniel.daugherty at oracle.com  Fri Aug 30 10:33:06 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Fri, 30 Aug 2013 17:33:06 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 18 new changesets
Message-ID: <20130830173431.B887062434@hg.openjdk.java.net>

Changeset: 1bb10d3170fa
Author:    jmasa
Date:      2013-08-16 06:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1bb10d3170fa

8022817: CMS should not shrink if compaction was not done
Reviewed-by: ysr, mgerdin

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: f7d3b4387a16
Author:    brutisso
Date:      2013-08-21 22:35 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f7d3b4387a16

8022872: G1: Use correct GC cause for young GC triggered by humongous allocations
Reviewed-by: tonyp, tschatzl

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp

Changeset: c31eb8c86a50
Author:    brutisso
Date:      2013-08-22 04:14 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c31eb8c86a50

Merge


Changeset: ec145d04eda8
Author:    jmasa
Date:      2013-08-23 15:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ec145d04eda8

Merge


Changeset: 1624a68007bd
Author:    jmasa
Date:      2013-08-27 18:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1624a68007bd

Merge

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: f92b82d454fa
Author:    bpittore
Date:      2013-08-23 20:33 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f92b82d454fa

8014135: The JVMTI specification does not conform to recent changes in JNI specification
Summary: Added support for statically linked agents
Reviewed-by: sspitsyn, bobv, coleenp

! src/os/posix/vm/os_posix.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/prims/jvmti.xml
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp

Changeset: 5fd8e2fbafd4
Author:    cjplummer
Date:      2013-08-23 12:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5fd8e2fbafd4

8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported
Summary: Make tests query a new WhiteBox API to see if NMT detail is supported, and behave properly if it is not supported.
Reviewed-by: dholmes, coleenp

! src/share/vm/prims/whitebox.cpp
! test/runtime/NMT/ThreadedVirtualAllocTestType.java
! test/runtime/NMT/VirtualAllocTestType.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 7aa0c1fb6fdb
Author:    dholmes
Date:      2013-08-27 22:05 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7aa0c1fb6fdb

8006164: [TESTBUG] compact profile hotspot test issues
Summary: Define profile-based test groups.
Reviewed-by: dcubed, mchung

! test/TEST.ROOT
+ test/TEST.groups

Changeset: 1fedf3c7f923
Author:    bpittore
Date:      2013-08-28 14:44 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1fedf3c7f923

8023580: Add jtreg test for 8004051 and 8005722
Summary: Tests checks an assertion dealing with the number of args passed in registers
Reviewed-by: mseledtsov, kvn

+ test/compiler/8004051/Test8004051.java

Changeset: b1fb293d92c4
Author:    jiangli
Date:      2013-08-28 12:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b1fb293d92c4

Merge


Changeset: 2b113b65a051
Author:    dholmes
Date:      2013-08-28 19:25 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2b113b65a051

8023900: [TESTBUG] Initial compact profile test groups need adjusting
Reviewed-by: dcubed, mchung, hseigel

! test/TEST.groups

Changeset: 54dfd798deaf
Author:    dholmes
Date:      2013-08-28 21:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/54dfd798deaf

Merge


Changeset: 62f527c674d2
Author:    dholmes
Date:      2013-08-29 00:22 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/62f527c674d2

Merge

! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp

Changeset: b649cfa58604
Author:    cl
Date:      2013-08-29 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b649cfa58604

Added tag jdk8-b105 for changeset acac3bde66b2

! .hgtags

Changeset: 18b4798adbc4
Author:    amurillo
Date:      2013-08-30 00:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/18b4798adbc4

Merge

- test/runtime/7051189/Xchecksig.sh

Changeset: aed585cafc0d
Author:    amurillo
Date:      2013-08-30 00:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aed585cafc0d

Added tag hs25-b48 for changeset 18b4798adbc4

! .hgtags

Changeset: c169f7038414
Author:    amurillo
Date:      2013-08-30 00:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c169f7038414

8024022: new hotspot build - hs25-b49
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: c636758ea616
Author:    dcubed
Date:      2013-08-30 07:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c636758ea616

Merge

! src/os/posix/vm/os_posix.cpp
- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp


From coleen.phillimore at oracle.com  Fri Aug 30 11:25:24 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 30 Aug 2013 14:25:24 -0400
Subject: S RFR JDK-8024050: Incorrect optimization level and comment
	specified for unsafe.cpp
In-Reply-To: <5220D3D3.3090802@oracle.com>
References: <5220C53F.8020705@oracle.com> <5220D3D3.3090802@oracle.com>
Message-ID: <5220E394.7070006@oracle.com>

This looks good.
Coleen

On 8/30/2013 1:18 PM, Lois Foltan wrote:
>
> Please review the following fix:
>     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8024050/
>
> Bug: bug link at https://bugs.openjdk.java.net/browse/JDK-8024050
>
> Summary of fix:
>
>     The original sources used for the JDK-8022407 webrev sponsorship 
> contained an incorrect optimization
>     level specification for unsafe.cpp that was fixed on the MacOS 
> machine prior to testing.  Unfortunately,
>     this incorrect specification of -01 instead of -O1 was committed.  
> In addition, corrected the comment for
>     the Clang optimization level skew issue between PCH Files and 
> files of different optimization levels.
>
> Tests:
>     MacOS: built fastdebug & product images using clang++ and llvm-g++ 
> Ran original JDK-8022407 test case.
>                   JTREG testing in progress.
>
> Thank you,
> Lois
>
>


From harold.seigel at oracle.com  Fri Aug 30 11:29:23 2013
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 30 Aug 2013 14:29:23 -0400
Subject: S RFR JDK-8024050: Incorrect optimization level and comment
	specified for unsafe.cpp
In-Reply-To: <5220E394.7070006@oracle.com>
References: <5220C53F.8020705@oracle.com> <5220D3D3.3090802@oracle.com>
	<5220E394.7070006@oracle.com>
Message-ID: <5220E483.7010809@oracle.com>

This looks good to me, also.

Thanks, Harold

On 8/30/2013 2:25 PM, Coleen Phillimore wrote:
> This looks good.
> Coleen
>
> On 8/30/2013 1:18 PM, Lois Foltan wrote:
>>
>> Please review the following fix:
>>     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8024050/
>>
>> Bug: bug link at https://bugs.openjdk.java.net/browse/JDK-8024050
>>
>> Summary of fix:
>>
>>     The original sources used for the JDK-8022407 webrev sponsorship 
>> contained an incorrect optimization
>>     level specification for unsafe.cpp that was fixed on the MacOS 
>> machine prior to testing.  Unfortunately,
>>     this incorrect specification of -01 instead of -O1 was 
>> committed.  In addition, corrected the comment for
>>     the Clang optimization level skew issue between PCH Files and 
>> files of different optimization levels.
>>
>> Tests:
>>     MacOS: built fastdebug & product images using clang++ and 
>> llvm-g++ Ran original JDK-8022407 test case.
>>                   JTREG testing in progress.
>>
>> Thank you,
>> Lois
>>
>>
>


From zhengyu.gu at oracle.com  Fri Aug 30 12:51:32 2013
From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com)
Date: Fri, 30 Aug 2013 19:51:32 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets
Message-ID: <20130830195140.54BCF6243F@hg.openjdk.java.net>

Changeset: 522d69638aa8
Author:    zgu
Date:      2013-08-30 11:54 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/522d69638aa8

6991327: using -Xprof trigger native memory leak
Summary: Fixed a memory leak in FlatProfiler::record_thread_tick() method
Reviewed-by: dholmes, ccheung

! src/share/vm/runtime/fprofiler.cpp

Changeset: 491de79915eb
Author:    zgu
Date:      2013-08-30 12:22 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/491de79915eb

Merge

! src/share/vm/runtime/fprofiler.cpp

Changeset: ac2764460da7
Author:    zgu
Date:      2013-08-30 13:38 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ac2764460da7

Merge



From lois.foltan at oracle.com  Fri Aug 30 12:57:19 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 30 Aug 2013 15:57:19 -0400
Subject: S RFR JDK-8024050: Incorrect optimization level and comment
	specified for unsafe.cpp
In-Reply-To: <f573f887-e8ee-4a36-8564-028f4a9a0137@default>
References: <5220C53F.8020705@oracle.com> <5220D3D3.3090802@oracle.com>
	<f573f887-e8ee-4a36-8564-028f4a9a0137@default>
Message-ID: <5220F91F.2080202@oracle.com>

Thanks Ron for the review!

Lois

On 8/30/2013 1:28 PM, Ron Durbin wrote:
> Lois I am unofficial reviewer, but the change looks good.
>
> Ron
>
>> -----Original Message-----
>> From: Lois Foltan
>> Sent: Friday, August 30, 2013 11:18 AM
>> To: hotspot-runtime-dev at openjdk.java.net; build-dev at openjdk.java.net
>> Subject: S RFR JDK-8024050: Incorrect optimization level and comment specified for
>> unsafe.cpp
>>
>>
>> Please review the following fix:
>>       open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8024050/
>>
>> Bug: bug link at https://bugs.openjdk.java.net/browse/JDK-8024050
>>
>> Summary of fix:
>>
>>       The original sources used for the JDK-8022407 webrev sponsorship contained an incorrect
>> optimization
>>       level specification for unsafe.cpp that was fixed on the MacOS machine prior to
>> testing.  Unfortunately,
>>       this incorrect specification of -01 instead of -O1 was committed.
>> In addition, corrected the comment for
>>       the Clang optimization level skew issue between PCH Files and files of different
>> optimization levels.
>>
>> Tests:
>>       MacOS: built fastdebug & product images using clang++ and llvm-g++ Ran original JDK-
>> 8022407 test case.
>>                     JTREG testing in progress.
>>
>> Thank you,
>> Lois
>>
>>


From lois.foltan at oracle.com  Fri Aug 30 12:58:38 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 30 Aug 2013 15:58:38 -0400
Subject: S RFR JDK-8024050: Incorrect optimization level and comment
	specified for unsafe.cpp
In-Reply-To: <5220E394.7070006@oracle.com>
References: <5220C53F.8020705@oracle.com> <5220D3D3.3090802@oracle.com>
	<5220E394.7070006@oracle.com>
Message-ID: <5220F96E.1090007@oracle.com>

Thanks Coleen for the review!

Lois

On 8/30/2013 2:25 PM, Coleen Phillimore wrote:
> This looks good.
> Coleen
>
> On 8/30/2013 1:18 PM, Lois Foltan wrote:
>>
>> Please review the following fix:
>>     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8024050/
>>
>> Bug: bug link at https://bugs.openjdk.java.net/browse/JDK-8024050
>>
>> Summary of fix:
>>
>>     The original sources used for the JDK-8022407 webrev sponsorship 
>> contained an incorrect optimization
>>     level specification for unsafe.cpp that was fixed on the MacOS 
>> machine prior to testing.  Unfortunately,
>>     this incorrect specification of -01 instead of -O1 was 
>> committed.  In addition, corrected the comment for
>>     the Clang optimization level skew issue between PCH Files and 
>> files of different optimization levels.
>>
>> Tests:
>>     MacOS: built fastdebug & product images using clang++ and 
>> llvm-g++ Ran original JDK-8022407 test case.
>>                   JTREG testing in progress.
>>
>> Thank you,
>> Lois
>>
>>
>


From lois.foltan at oracle.com  Fri Aug 30 13:00:29 2013
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 30 Aug 2013 16:00:29 -0400
Subject: S RFR JDK-8024050: Incorrect optimization level and comment
	specified for unsafe.cpp
In-Reply-To: <5220E483.7010809@oracle.com>
References: <5220C53F.8020705@oracle.com> <5220D3D3.3090802@oracle.com>
	<5220E394.7070006@oracle.com> <5220E483.7010809@oracle.com>
Message-ID: <5220F9DD.2000406@oracle.com>

Thanks Harold for the review!

Lois

On 8/30/2013 2:29 PM, harold seigel wrote:
> This looks good to me, also.
>
> Thanks, Harold
>
> On 8/30/2013 2:25 PM, Coleen Phillimore wrote:
>> This looks good.
>> Coleen
>>
>> On 8/30/2013 1:18 PM, Lois Foltan wrote:
>>>
>>> Please review the following fix:
>>>     open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8024050/
>>>
>>> Bug: bug link at https://bugs.openjdk.java.net/browse/JDK-8024050
>>>
>>> Summary of fix:
>>>
>>>     The original sources used for the JDK-8022407 webrev sponsorship 
>>> contained an incorrect optimization
>>>     level specification for unsafe.cpp that was fixed on the MacOS 
>>> machine prior to testing.  Unfortunately,
>>>     this incorrect specification of -01 instead of -O1 was 
>>> committed.  In addition, corrected the comment for
>>>     the Clang optimization level skew issue between PCH Files and 
>>> files of different optimization levels.
>>>
>>> Tests:
>>>     MacOS: built fastdebug & product images using clang++ and 
>>> llvm-g++ Ran original JDK-8022407 test case.
>>>                   JTREG testing in progress.
>>>
>>> Thank you,
>>> Lois
>>>
>>>
>>
>


From harold.seigel at oracle.com  Fri Aug 30 15:39:41 2013
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Fri, 30 Aug 2013 22:39:41 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets
Message-ID: <20130830223950.AD61E62446@hg.openjdk.java.net>

Changeset: ca0501b58953
Author:    hseigel
Date:      2013-08-30 15:07 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ca0501b58953

8024050: Incorrect optimization level and comment specified for unsafe.cpp
Summary: Fix comments and optimization level.
Reviewed-by: rdurbin, coleenp, hseigel
Contributed-by: lois.foltan at oracle.com

! make/bsd/makefiles/gcc.make

Changeset: d8ff06fb87ae
Author:    hseigel
Date:      2013-08-30 15:15 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d8ff06fb87ae

Merge


Changeset: abff50660360
Author:    hseigel
Date:      2013-08-30 15:57 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/abff50660360

Merge



From christian.thalinger at oracle.com  Fri Aug 30 16:34:01 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 30 Aug 2013 16:34:01 -0700
Subject: RFR JDK-8022407 (round 2) sun/misc/CopyMemory.java fails with
	SIGSEGV in Unsafe_SetByte+0x35
In-Reply-To: <52209FCE.6000005@oracle.com>
References: <521CD14D.5040809@oracle.com> <521E39DB.1050901@oracle.com>
	<521F2D7F.5030001@oracle.com> <521F381B.5090005@oracle.com>
	<52200110.7030400@oracle.com> <52209FCE.6000005@oracle.com>
Message-ID: <86DA22FF-B13F-44CC-BCC9-C31232600E86@oracle.com>


On Aug 30, 2013, at 6:36 AM, Lois Foltan <lois.foltan at oracle.com> wrote:

> 
> On 8/29/2013 10:18 PM, David Holmes wrote:
>> On 29/08/2013 10:01 PM, Lois Foltan wrote:
>>> 
>>> On 8/29/2013 7:16 AM, David Holmes wrote:
>>>> Hi Lois,
>>>> 
>>>> Is this still needed:
>>>> 
>>>> 142     PCH_FLAG/unsafe.o = $(PCH_FLAG/NO_PCH)
>>>> 
>>>> given you no longer use -O0 ?
>>> Hi David,
>>> Yes, I believe so but this might be a cautionary change on my part. I
>>> read the comment to imply that Clang does not support a precompiled
>>> header compiled with an optimization level that is different than the
>>> one used to compile the actual C++ file, this is why I chose to add
>>> unsafe.o.
>> 
>> I read the comment as only applying to a combination of -O0 with -O3. So now the comment is inaccurate as it claims all files are compiled with -O0.
>> 
>> 133     # There are some files which don't like precompiled headers
>> 134     # The following files are build with 'OPT_CFLAGS/NOOPT' (-O0) in the opt build.
>> 135     # But Clang doesn't support a precompiled header which was compiled with -O3
>> 136     # to be used in a compilation unit which uses '-O0'. We could also prepare an
>> 137     # extra '-O0' PCH file for the opt build and use it here, but it's probably
>> 138     # not worth the effort as long as only two files need this special handling.
>> 
>> Either the comment or the entry at line 142 need to be changed. (the part about 'two files' is already out of date :( )
> 
> Hi David,
> Line #142 is necessary.  If clang++ compiles unsafe.o with -O1 and tries to include the precompiled header that is compiled by default with -Os, (note that -Os is the current default, not -O3 as the comment indicates)

That's because I took the comment verbatim from the Linux makefile.  Not good practice, I know.

-- Chris

> , the following compile time error is generated:
> 
>    error: __OPTIMIZE_SIZE__ predefined macro was enabled in PCH file but is currently disabled
> 
> So, the the comment is incorrect in many ways.  I have entered https://bugs.openjdk.java.net/browse/JDK-8024050, detailing the issues.
> 
> Thanks,
> Lois
> 
>> 
>> David
>> -----
>> 
>>> Lois
>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>> On 29/08/2013 3:56 AM, Lois Foltan wrote:
>>>>> 
>>>>> Please review the updated webrev:
>>>>>     open webrev at
>>>>> http://cr.openjdk.java.net/~hseigel/bug_jdk8022407.2/
>>>>> 
>>>>> Bug:
>>>>>     bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>>>> 
>>>>> Summary of fix:
>>>>> 
>>>>>     The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++
>>>>> compiler, exhibited a compiler
>>>>>     optimization issue when prims/unsafe.cpp was compiled at the
>>>>> default -Os level. As a work around
>>>>>     fix, knock the optimization level down down to -O1.
>>>>> 
>>>>> Tests: MacOS: built fastdebug & product images using clang++ (ran JTREG
>>>>> & vm.quick.testlist)
>>>>>           built using llvm-g++ to verifyprims/unsafe.cpp remained
>>>>> compiled at -Os
>>>>> 
>>>>> Thank you, Lois
>>>>> 
>>>>> 
>>> 
> 


From karen.kinnear at oracle.com  Fri Aug 30 17:59:37 2013
From: karen.kinnear at oracle.com (karen.kinnear at oracle.com)
Date: Sat, 31 Aug 2013 00:59:37 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets
Message-ID: <20130831005946.3112262456@hg.openjdk.java.net>

Changeset: 3a1df0dce3e5
Author:    acorn
Date:      2013-08-30 15:15 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3a1df0dce3e5

8023872: Verification error in generated lambda classes
Summary: skip verification for generated lambda classes
Reviewed-by: kamg, dholmes

! src/share/vm/classfile/verifier.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 735f94656acc
Author:    acorn
Date:      2013-08-30 12:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/735f94656acc

Merge


Changeset: 2918c7e21a3a
Author:    acorn
Date:      2013-08-30 15:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2918c7e21a3a

Merge



From ioi.lam at oracle.com  Fri Aug 30 18:15:21 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 30 Aug 2013 18:15:21 -0700
Subject: RFR (S) 8022335 - (round 2) Native stack walk on Windows x64
In-Reply-To: <CA+3eh11Bfy0kN4tfN-f5DYa5=7CrbLC_vjdSbFnsr_xFRfE_yQ@mail.gmail.com>
References: <521FCD16.10600@oracle.com>
	<CA+3eh11Bfy0kN4tfN-f5DYa5=7CrbLC_vjdSbFnsr_xFRfE_yQ@mail.gmail.com>
Message-ID: <522143A9.6070101@oracle.com>

On 08/30/2013 07:32 AM, Volker Simonis wrote:
>
>
> On Fri, Aug 30, 2013 at 12:37 AM, Ioi Lam <ioi.lam at oracle.com 
> <mailto:ioi.lam at oracle.com>> wrote:
> > Please review this fix:
> >
> > http://cr.openjdk.java.net/~iklam/8022335/win64_stack_walk_002/ 
> <http://cr.openjdk.java.net/%7Eiklam/8022335/win64_stack_walk_002/>
> >
> > Bug: Native stack walk while generating hs_err does not work on 
> Windows x64
> >
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022335
> > https://bugs.openjdk.java.net/browse/JDK-8022335
> >
> > What's new:
> >
> >     The code is much more simplified than my last version. All 
> interesting
> >     code is in a single function -- os::platform_print_native_stack
> >     in os_windows_x86.cpp. The rest is just busy work.
> >
> > Summary of fix:
> >
> >     Windows x64 binaries are built (unconditionally) with the 
> equivalent of
> >     -fomit-frame-pointer,
>
> Why do you think so? If I'm looking at the build logs and 
> make/windows/makefiles/compile.make I see that we always compile with 
> '/O2 /Oy-' which according to 
> http://msdn.microsoft.com/en-us/library/2kxx5t2c%28v=vs.100%29.aspx 
> means 'disable frame-pointer omission'. So according to that 
> documentation, we should have frame pointers in all functions.
>
> Actually '/Oy-' was introduced in order to get better native stack 
> traces with http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6655385
> Doesn?t it help or are there any other additional problem?
>

/Oy is for x86 only. It has no effect on x64. As mentioned in the MSDN 
link above

     "/Oy enables frame-pointer omission and /Oy- disables omission. /Oy 
is available only in x86 compilers."

^ This was also discussed in the 
https://bugs.openjdk.java.net/browse/JDK-8022335page. Unfortunately it's 
not (yet?) available to the public :-(

More info about the x64 stack can be found here
http://msdn.microsoft.com/en-us/library/ew5tede7.aspx
http://www.codejury.com/a-walk-in-x64-land/

Essentially

    Fixed frames are always addressed via RSP only.

    Dynamic frames (when alloca() is used), a frame pointer register is 
used.
    But this register is not necessary RBP.

> Currently I get the following in the hs_err file on Windows for a Java 
> program which crashes in Unsafe:
>
> # JRE version: OpenJDK Runtime Environment (8.0) (build 
> 1.8.0-internal-fastdebug-_2013_08_29_21_12-b00)
> # Java VM: OpenJDK 64-Bit Server VM (25.0-b45-fastdebug mixed mode 
> windows-amd64 compressed oops)
> # Problematic frame:
> # V  [jvm.dll+0x28c7a7]
> ...
> *Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
> C=native code)
> V  [jvm.dll+0x28c7a7]
> J  Crash.crashIt(Lsun/misc/Unsafe;I)V @ 0x0000000008e9b19c 
> [0x0000000008e9b140+92]
> v  ~StubRoutines::call_stub
> V  [jvm.dll+0x2c961a]
> *
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  sun.misc.Unsafe.putAddress(JJ)V+0
> J  Crash.crashIt(Lsun/misc/Unsafe;I)V @ 0x0000000008e9b19c 
> [0x0000000008e9b140+92]
> j  Crash.doIt()V+45
> v  ~StubRoutines::call_stub
> j 
>  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
> j 
>  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
> j 
>  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
> j 
>  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+56
> j  Crash.main([Ljava/lang/String;)V+32
> v  ~StubRoutines::call_stub
>
>
> On Linux, the same crashing program produces the following output in 
> the hs_err file:
>
> # JRE version: OpenJDK Runtime Environment (8.0) (build 
> 1.8.0-internal-jvmtests_2013_08_29_20_14-b00)
> # Java VM: OpenJDK 64-Bit Server VM (25.0-b45 mixed mode linux-amd64 
> compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x9b4ba7]  Unsafe_SetNativeAddress+0xa7
> ...
> *Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
> C=native code)
> V  [libjvm.so+0x9b4ba7]  Unsafe_SetNativeAddress+0xa7
> j  sun.misc.Unsafe.putAddress(JJ)V+0
> J  Crash.crashIt(Lsun/misc/Unsafe;I)V @ 0x00007f0b4d0f2c9c 
> [0x00007f0b4d0f2b80+284]
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x6174ee]  JavaCalls::call_helper(JavaValue*, 
> methodHandle*, JavaCallArguments*, Thread*)+0x104e
> V  [libjvm.so+0x8c2e12]  Reflection::invoke(instanceKlassHandle, 
> methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle, 
> bool, Thread*)+0x5e2
> V  [libjvm.so+0x8c63e7]  Reflection::invoke_method(oopDesc*, Handle, 
> objArrayHandle, Thread*)+0x147
> V  [libjvm.so+0x66dd8e]  JVM_InvokeMethod+0x25e
> j 
>  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
> j 
>  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
> j 
>  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
> j 
>  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+56
> j  Crash.main([Ljava/lang/String;)V+32
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x6174ee]  JavaCalls::call_helper(JavaValue*, 
> methodHandle*, JavaCallArguments*, Thread*)+0x104e
> V  [libjvm.so+0x631226]  jni_invoke_static(JNIEnv_*, JavaValue*, 
> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x346
> V  [libjvm.so+0x63b98a]  jni_CallStaticVoidMethod+0x17a
> C  [libjli.so+0x75ed]  JavaMain+0x83d*
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  sun.misc.Unsafe.putAddress(JJ)V+0
> J  Crash.crashIt(Lsun/misc/Unsafe;I)V @ 0x00007f0b4d0f2c9c 
> [0x00007f0b4d0f2b80+284]
> j  Crash.doIt()V+45
> v  ~StubRoutines::call_stub
> j 
>  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
> j 
>  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
> j 
>  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
> j 
>  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+56
> j  Crash.main([Ljava/lang/String;)V+32
> v  ~StubRoutines::call_stub
>
> So while the native (i.e. "mixed") stack trace is still much more 
> accurate on Linux, it isn't just a single line as you wrote. Maybe we 
> could work on improving this situation on Windows without a separate 
> Windows stack tracing routine or are there any fundamental problems 
> which prevent this?
>

Thank you for the test case. It makes my testing a lot easier!

Unfortunately you can walk the stack in this case only because you're 
lucky. I have disassembled Unsafe_SetNativeAddress, up to the point of 
the crash:

    UNSAFE_ENTRY(void, Unsafe_SetNativeAddress(JNIEnv *env, jobject
    unsafe, jlong addr, jlong x))
    000000006CD106D0  mov         qword ptr [rsp+8],rbx
    000000006CD106D5  mov         qword ptr [rsp+10h],rsi
    000000006CD106DA  push        rdi
    000000006CD106DB  sub         rsp,20h
    000000006CD106DF  mov         eax,dword ptr [rcx+90h]
    000000006CD106E5  lea         rbx,[rcx-1E0h]
    000000006CD106EC  mov         rdi,r9
    000000006CD106EF  mov         rsi,r8
    000000006CD106F2  cmp         eax,0DEABh
    000000006CD106F7  je          Unsafe_SetNativeAddress+40h (06CD10710h)
    000000006CD106F9  mov         eax,dword ptr [rbx+270h]
    000000006CD106FF  cmp         eax,0DEACh
    000000006CD10704  je          Unsafe_SetNativeAddress+40h (06CD10710h)
    000000006CD10706  mov         rcx,rbx
    000000006CD10709  call        JavaThread::block_if_vm_exited
    (06CD53AF0h)
    000000006CD1070E  xor         ebx,ebx
    000000006CD10710  mov         dword ptr [rbx+258h],5
    000000006CD1071A  cmp         dword ptr [os::_processor_count
    (06CEB287Ch)],1
    000000006CD10721  jg          Unsafe_SetNativeAddress+5Ch (06CD1072Ch)
    000000006CD10723  cmp         byte ptr [AssumeMP (06CEB1FDCh)],0
    000000006CD1072A  je          Unsafe_SetNativeAddress+74h (06CD10744h)
    000000006CD1072C  cmp         byte ptr [UseMembar (06CEB1FDDh)],0
    000000006CD10733  je          Unsafe_SetNativeAddress+6Ch (06CD1073Ch)
    000000006CD10735  call        OrderAccess::StubRoutines_fence
    (06CD36BC0h)
    000000006CD1073A  jmp         Unsafe_SetNativeAddress+74h (06CD10744h)
    000000006CD1073C  mov         rcx,rbx
    000000006CD1073F  call InterfaceSupport::serialize_memory (06CA59A10h)
    000000006CD10744  mov         eax,dword ptr
    [SafepointSynchronize::_state (06CEB2988h)]
    000000006CD1074A  test        eax,eax
    000000006CD1074C  jne         Unsafe_SetNativeAddress+88h (06CD10758h)
    000000006CD1074E  mov         eax,dword ptr [rbx+30h]
    000000006CD10751  test        eax,30000000h
    000000006CD10756  je          Unsafe_SetNativeAddress+90h (06CD10760h)
    000000006CD10758  mov         rcx,rbx
    000000006CD1075B  call
    JavaThread::check_safepoint_and_suspend_for_native_trans (06CD53F20h)
    000000006CD10760  mov         dword ptr [rbx+258h],6
       UnsafeWrapper("Unsafe_SetNativeAddress");
       void* p = addr_from_java(addr);
       *(void**)p = addr_from_java(x);
    000000006CD1076A  mov         qword ptr [rsi],rdi <<<<<<<<<<<<<<<< CRASH
    UNSAFE_END

Notice that RBP is never used, so it keeps the old value of the caller 
(Java frame: sun.misc.Unsafe.putAddress). All Java frames in x64 still 
use the "push RBP; mov RBP, RSP" prolog, so they can be walked by the 
existing code.

I have generated my own stack traces (with jvm.dll symbols for Windows). 
If you compare the Windows and Linux versions:

*Linux
*    V  [libjvm.so+0x663d77]  Unsafe_SetNativeAddress+0x183
     j  sun.misc.Unsafe.putAddress(JJ)V+0<<<<---- missing from Windows
     j  sun.misc.Crash.main([Ljava/lang/String;)V+17
     v  ~StubRoutines::call_stub

*Windows*
     V  [jvm.dll+0x5d1420]  Unsafe_SetNativeAddress+0x140
     j  sun.misc.Crash.main([Ljava/lang/String;)V+17
     v  ~StubRoutines::call_stub

Note that the Windows version is missing sun.misc.Unsafe.putAddress. 
That's because the top most frame was actually printed using the RBP of 
the (Java) frame of sun.misc.Unsafe.putAddress, while using the native 
PC of Unsafe_SetNativeAddress.

If the scenario is more complicated (you have a few nested native calls, 
or if the native code overwrites RBP), then you will end up with a 
single native frame. You can see that by inserting crashes inside the 
class classLoader.cpp, etc.

So, with the existing code, it will give at most 1 native frame, plus a 
few Java frames (if you're lucky), but we already know the Java frames, 
so really it doesn't add any information.

With my patch, you will see the full native stack, up to the first Java 
frame. I think this has a lot of value for debugging (when MDMP files 
are not available).

What is still missing, are the frames below the first bunch of Java 
frames. To do this in all cases (e.g., when alloca() is used), I need to 
be able to recover all the non-volatile registers that are touched by 
the Java frames (because any non-volatile register could be a WinX64 
frame pointer!). This is probably doable, but I am not feeling brave 
enough to do this so late into JDK8.

BTW, StackWalk64() actually restores all the non-volatile registers 
(into the CONTEXT structure) as it unwinds the stack. It can do this 
because all the locations of the non-volatile registers are well 
specified in the PE32+ file format.See
http://www.codejury.com/a-walk-in-x64-land/

> >     so HotSpot's build-in native stack walking code
> >     will fail to find the sender frame. As a result, hs_err on 
> Windows/x64
> >     will always list a single frame.
> >
> >     I have added the os::platform_print_native_stack() function for
> >     Windows/x64 only. It uses the StackWalk64 API to walk the stace.
> >
> >     Because the Win/x64 frame layout is very different than what HotSpot
> > expects,
> >     I decided to implement os::platform_print_native_stack() as a 
> completely
> >     stand-alone function, and do not interact with the existing 
> "frame" C++
> > class.
> >     See comments in os_windows_x86.cpp for details.
> >
> > Deficiency of fix:
> >
> >     StackWalk64 knows nothing about the Java frames. So hs_err will 
> display
> > only
> >     the native frames, and stop as soon as the first Java frame is 
> reached.
> > It will
> >     also NOT display any native frames below Java frames.
> >
> >     Printing the Java frames *may* be possible. However, at this 
> point, I
> > want
> >     to keep the code simple and crash proof. I will file a different 
> bug for
> >     printing the Java frames.
> >
> > Bonus:
> >
> >     As a side-fix, I refactored a bunch of duplicated code in 
> decoder.cpp
> > into
> >     the DecoderLocker class.
> >
>
> I would really appreciate if you could do this in a separate change. I 
> think it is commonly agreed upon that "small unrelated fixes" (like 
> comments, white-space changes or single line fixes) may go into 
> another change but these changes are in IMHO big enough to justify a 
> different bug ID and change set.
>
Agreed. I will use the DecoderLocker only for my new code (to avoid 
cut-and-paste error of duplicated code blocks), but will not touch the 
existing code. I will do the clean up with a separate RFE.

> > Tests:
> >
> >     JPRT
> >     UTE (vm.runtime.testlist, vm.quick.testlist,
> > vm.parallel_class_loading.testlist)
> >
> >     I also manually inserted some crashes into jvm.dll and verified 
> that the
> >     native stack trace is printed as expected on Win/x64.
> >
>
> Maybe you can use/extend the WhiteBox API to write some good tests?
>
I'll try to this this.

Thanks!

- Ioi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130830/2b40cb95/attachment-0001.html 

From yumin.qi at oracle.com  Fri Aug 30 23:36:14 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 30 Aug 2013 23:36:14 -0700
Subject: RFR: 7164841: Improvements to the GC log file rotation
In-Reply-To: <521542A3.3020906@oracle.com>
References: <520CF52B.6050000@oracle.com> <521542A3.3020906@oracle.com>
Message-ID: <52218EDE.4060508@oracle.com>

Hi, all


   With more feedback on the second version, the third version make 
following changes:

   1) take parametrized filename after -Xloggc:, the filename will be 
forced to follow following rules:
       can only contain [A-Z][a-z][0-9].-_%[p|t], any other character 
used for file name will be rejected. %p or %t can only appear once in 
file name.
       example:  -Xloggc:test.log-%t-%p           OK
       example: -Xloggc:test.log-%p-%p           FAIL

    2) removed unused rotatingFileStream constructors

    3) log more information at head of rotation file:
        vm version, os version, build id etc
        memory usage
        commandline  flags

    Tested on Linux/Windows

    URL: http://cr.openjdk.java.net/~minqi/7164841/webrev0 
<http://cr.openjdk.java.net/%7Eminqi/7164841/webrev0>2

   Thanks
   Yumin

On 8/21/2013 3:43 PM, Yumin Qi wrote:
> Hi, all
>
>   This is second version after feedback from first round.
>   The changes are:
>
>   1) file name will be based on gc log file name (-Xloggc:filename), 
> pid (process id) and time when the first rotation file created:
>        <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS
>   2) If rotate in same file, file name is as in 1), if rotate in 
> multiple files, .<i> will append to above file name.
>   3) every time file rotated, file name and time when file created 
> will be logged to head/tail, this is same as first version.
>   4) current file has name 
> <filename>-pid<pid>-YYYY-MM-DD_HH-MM-SS.<i>.current
>        This is similar to first version.
>        By adapting such name format we will never loss logs in case 
> apps stops and restart, the log files will not be overwritten since 
> time stamp in file names.
>    5) If open file failed, turn off gc log rotation.
>         If due to some reason, file operation failed (such as 
> permission changed etc), with log file opened, logging still works, 
> but at
>         saving and renaming, the file operation will fail, this will 
> lead not all files saved.
>
> http://cr.openjdk.java.net/~minqi/7164841/webrev01
>
>      Tested with jtreg, JPRT.
>
> Thanks
> Yumin
>
> On 8/15/2013 8:35 AM, Yumin Qi wrote:
>> Hi,
>>
>>   Can I have your review for this small changes?
>> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ 
>> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/>
>>
>>    This is for a enhancement to add head/tail message to the logging 
>> files to assist reading GC output.
>>    1. modified prompt message if invalid arguments used for log rotating;
>>    2. add time and file name message to log file head/tail.
>>    3. for easily identify which log file is current, use file name 
>> like <filename>.n.current, after it reaches maximum size, rename it 
>> to <filename>.n
>>         On Windows, there is no F_OK (existing test) definition, F_OK 
>> is defined as "0" and for _access of VC++, it just describes:
>>
>> modevalue
>>
>> 	
>>
>> Checks file for
>>
>> 00
>>
>> 	
>>
>> Existence only
>>
>> 02
>>
>> 	
>>
>> Write-only
>>
>> 04
>>
>> 	
>>
>> Read-only
>>
>> 06
>>
>> 	
>>
>> Read and write
>>
>>
>> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
>> The definition are consistent with unistd.h.
>>
>>     Test: JPRT and jtreg.
>>
>>    Thanks
>>    Yumin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130830/c807d53e/attachment.html 

From david.holmes at oracle.com  Sat Aug 31 04:57:33 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 31 Aug 2013 21:57:33 +1000
Subject: RFR JDK-8022407 (round 2) sun/misc/CopyMemory.java fails with
	SIGSEGV in Unsafe_SetByte+0x35
In-Reply-To: <52209FCE.6000005@oracle.com>
References: <521CD14D.5040809@oracle.com> <521E39DB.1050901@oracle.com>
	<521F2D7F.5030001@oracle.com> <521F381B.5090005@oracle.com>
	<52200110.7030400@oracle.com> <52209FCE.6000005@oracle.com>
Message-ID: <5221DA2D.7070707@oracle.com>

On 30/08/2013 11:36 PM, Lois Foltan wrote:
> On 8/29/2013 10:18 PM, David Holmes wrote:
>> On 29/08/2013 10:01 PM, Lois Foltan wrote:
>>>
>>> On 8/29/2013 7:16 AM, David Holmes wrote:
>>>> Hi Lois,
>>>>
>>>> Is this still needed:
>>>>
>>>>  142     PCH_FLAG/unsafe.o = $(PCH_FLAG/NO_PCH)
>>>>
>>>> given you no longer use -O0 ?
>>> Hi David,
>>> Yes, I believe so but this might be a cautionary change on my part. I
>>> read the comment to imply that Clang does not support a precompiled
>>> header compiled with an optimization level that is different than the
>>> one used to compile the actual C++ file, this is why I chose to add
>>> unsafe.o.
>>
>> I read the comment as only applying to a combination of -O0 with -O3.
>> So now the comment is inaccurate as it claims all files are compiled
>> with -O0.
>>
>> 133     # There are some files which don't like precompiled headers
>> 134     # The following files are build with 'OPT_CFLAGS/NOOPT' (-O0)
>> in the opt build.
>> 135     # But Clang doesn't support a precompiled header which was
>> compiled with -O3
>> 136     # to be used in a compilation unit which uses '-O0'. We could
>> also prepare an
>> 137     # extra '-O0' PCH file for the opt build and use it here, but
>> it's probably
>> 138     # not worth the effort as long as only two files need this
>> special handling.
>>
>> Either the comment or the entry at line 142 need to be changed. (the
>> part about 'two files' is already out of date :( )
>
> Hi David,
> Line #142 is necessary.  If clang++ compiles unsafe.o with -O1 and tries
> to include the precompiled header that is compiled by default with -Os,
> (note that -Os is the current default, not -O3 as the comment
> indicates), the following compile time error is generated:
>
>      error: __OPTIMIZE_SIZE__ predefined macro was enabled in PCH file
> but is currently disabled
>
> So, the the comment is incorrect in many ways.  I have entered
> https://bugs.openjdk.java.net/browse/JDK-8024050, detailing the issues.

Ok. Thanks for that.

David

> Thanks,
> Lois
>
>>
>> David
>> -----
>>
>>> Lois
>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 29/08/2013 3:56 AM, Lois Foltan wrote:
>>>>>
>>>>> Please review the updated webrev:
>>>>>      open webrev at
>>>>> http://cr.openjdk.java.net/~hseigel/bug_jdk8022407.2/
>>>>>
>>>>> Bug:
>>>>>      bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
>>>>>
>>>>> Summary of fix:
>>>>>
>>>>>      The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++
>>>>> compiler, exhibited a compiler
>>>>>      optimization issue when prims/unsafe.cpp was compiled at the
>>>>> default -Os level. As a work around
>>>>>      fix, knock the optimization level down down to -O1.
>>>>>
>>>>> Tests: MacOS: built fastdebug & product images using clang++ (ran
>>>>> JTREG
>>>>> & vm.quick.testlist)
>>>>>            built using llvm-g++ to verifyprims/unsafe.cpp remained
>>>>> compiled at -Os
>>>>>
>>>>> Thank you, Lois
>>>>>
>>>>>
>>>
>