Re: Request for review:8023477: Invalid CP index when reading ConstantPool

[Staffan Larsen]

Looks good.

Thanks,
/Staffan

On 23 aug 2013, at 23:49, Jiangli Zhou jiangli.z...@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.z...@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.spit...@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.spit...@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
 
 
 

Re: Codereview requested: 6566891 RMIConnector: map value referencing map key in WeakHashMap prevents map entry to be removed

[shanliang]

Hi,

Still need OK from a reviewer.
Thanks Erik, Jaroslav and Daniel for the code review.

Thanks,
Shanliang

Daniel Fuchs wrote:

On 8/21/13 10:27 AM, shanliang wrote:

Jaroslav Bachorik wrote:

On 08/21/2013 12:00 AM, Daniel Fuchs wrote:


On 8/20/13 11:12 PM, shanliang wrote:


Thanks Daniel and Erik for the comments, here is new version:
http://cr.openjdk.java.net/~sjiang/JDK-6566891/01/

This new version looks reasonable. I guess you could dispense of 
the new
nullSubjectConnRef by just using 'null' as key in the WeakHashMap 
(as this

seems to be the way it  used to work before) - but I'm OK with your
proposed changes.



Indeed, the change could be simplified by just using the null key.


If using null as a key, then the pair null/weakRef will never be
removed from WeakHashMap, even the value of weakRef is null. Of course
this is a minor memory leak, or almost nothing, but it seems more clean
to use nullSubjectConnRef.


Ah. Good point. I didn't think of that...


Still need a reviewer.

Thanks,
Shanliang

The rest seems fine. Thumbs up!

-JB-



-- daniel


Erik Gahlin wrote:


Shanliang,

Let's say the delgationSubject is null and there is previous
connection cached (nullSubjectConn != null  nullSubjectConn.get()
!= null) so you hit:

2016: conn = nullSubjectConn.get();

but before you get the object a GC occurs and clears reference, then
getConnectionWithSubject would return null.

Shouldn't you assign to nullSubjectConn.get() to variable so the
reference is kept alive? Or it OK to return null?


Yes, should avoid calling 2 times.


Also, is the

2020: if (wr != null) {


This line is no more there.

Shanliang


necessary?

Thanks
Erik

nullSibwhen you hit the second if-statement
  happens
shanliang skrev 2013-08-20 17:35:


webrev:http://cr.openjdk.java.net/~sjiang/JDK-6566891/00/

shanliang wrote:


Hi,

Please review:

webrev:
http://amos.fr.oracle.com/jmgt/user/sjiang/webrevs/jdk8-6566891/00/ 


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

I have passed JCK tests and unit tests.

Thanks,
Shanliang

hg: jdk8/tl/jdk: 8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8)

[alan . bateman]

Changeset: 0ee3b995d63b
Author:alanb
Date:  2013-08-26 10:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ee3b995d63b

8023139: java/nio/file/WatchService/SensitivityModifier.java failing 
intermittently (win8)
Reviewed-by: alanb
Contributed-by: yiming.w...@oracle.com

! test/java/nio/file/WatchService/SensitivityModifier.java

Re: AsyncGetCallTrace java profiling

[Alexandre De Champeaux]

Hi,

I was able to reproduce the bug running java 8 (build b103, and so hotspot
build 25.0-b45). So I would like to update the bug report to java 8. I
don't have access to it though. Should I post a new one?


On Tue, Aug 13, 2013 at 2:13 PM, Alexandre De Champeaux
a...@quartetfs.comwrote:

 Ok thanks. I just posted a bug report to bugs.sun.com describing the
 issue (id 9005974).


 On Tue, Aug 13, 2013 at 1:00 PM, Alan Bateman alan.bate...@oracle.comwrote:

  On 13/08/2013 09:11, Alexandre De Champeaux wrote:

 Hi all,

  I posted this message a few days ago in the discuss mailing list. This
 one seems way more accurate though, so i am posting it again.

  Following his blog post (
 http://jeremymanson.blogspot.fr/2013/07/lightweight-asynchronous-sampling.html),
 I have been trying to use the code Jeremy Manson proposes to use the
 AsyncGetCallTrace function.
 Although it works smoothly on small examples, I see some impossible
 stacktraces on real world projects, with complex interface structures. I
 have posted a bug report that reproduces it and gives more details here :
 https://code.google.com/p/lightweight-java-profiler/issues/detail?id=1

  I am trying to estimate if those stacktraces are sparse (seems to be
 so), and so if a profiler that uses this feature will be reliable.

  Any known bugs / limitations of the AsyncGetCallTrace function?
 This function being undocumented, in what extent does it stays up to date?

  Thanks for your answers

  Alex

 When you say you've posted a bug report, does this mean to bugs.sun.com?
 While not technically supported, it is known to be used by some products so
 if there is an issue (and I remember this had a long bug tail originally)
 then it would be good to track it.

 -Alan.

hg: jdk8/tl/jdk: 7129312: BufferedInputStream calculates negative array size with large streams and mark

[alan . bateman]

Changeset: 67a1a031876a
Author:igerasim
Date:  2013-08-25 23:20 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67a1a031876a

7129312: BufferedInputStream calculates negative array size with large streams 
and mark
Reviewed-by: alanb

! src/share/classes/java/io/BufferedInputStream.java
+ test/java/io/BufferedInputStream/LargeCopyWithMark.java

Re: RFR(S): JDK-6622468 : TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

[David Holmes]

Staffan,

javaoptions will only be passed to the java invocation of the VM under test.

vmptions will be passed to all VM invocations including javac from the 
compile-jdk.


If your test-jdk and compile-jdk are the same then you will have trouble 
telling them apart :)


That aside I would have thought it quite reasonable for the debugger and 
debuggee VMs to need different options - hence the debuggeeVMOptions.


David

On 23/08/2013 9:26 PM, Staffan Larsen wrote:

The JDI tests have some quite arcane way of sending command line options to the 
debuggee. Options have to be put into a file called @debuggeeVMOptions before 
invoking jtreg. This was apparently implemented before there was a way in jtreg 
to set -vmoptions/-javaoptions.

I'd like to remove this crufty code and instead use the value of 
-vmoptions/-javaoptions when launching the debuggee. This would make it a lot 
simpler and more consistent to launch these tests.

The current test infrastructure puts the same options in @debuggeeVMOptions as 
in -javaoptions when launching the JDI tests.

I am not quite sure about the difference between -vmoptions and -javaoptions. 
It seems both are used to change the options of the JVM running the test. 
Because of this I pick up both values and forward them to the launching of the 
debuggee JVM. However, I can't see any other tests that use TESTJAVAOPTS, they 
all seem to use TESTVMOPTS. The problem with that for my case is that the test 
infrastructure uses -javaoptions instead of -vmoptions.

webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.00/
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6622468

Thanks,
/Staffan

Re: RFR(S): JDK-6622468 : TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

[Staffan Larsen]

On 26 aug 2013, at 13:03, David Holmes david.hol...@oracle.com wrote:

 Staffan,
 
 javaoptions will only be passed to the java invocation of the VM under test.
 
 vmptions will be passed to all VM invocations including javac from the 
 compile-jdk.

Thanks, that was what I thought. So if my VM under test wants to launch a new 
VM is would have to use javaoptions + vmoptions.

 
 If your test-jdk and compile-jdk are the same then you will have trouble 
 telling them apart :)
 
 That aside I would have thought it quite reasonable for the debugger and 
 debuggee VMs to need different options - hence the debuggeeVMOptions.

Do you have an example where this would be necessary?

Thanks,
/Staffan

 
 David
 
 On 23/08/2013 9:26 PM, Staffan Larsen wrote:
 The JDI tests have some quite arcane way of sending command line options to 
 the debuggee. Options have to be put into a file called @debuggeeVMOptions 
 before invoking jtreg. This was apparently implemented before there was a 
 way in jtreg to set -vmoptions/-javaoptions.
 
 I'd like to remove this crufty code and instead use the value of 
 -vmoptions/-javaoptions when launching the debuggee. This would make it a 
 lot simpler and more consistent to launch these tests.
 
 The current test infrastructure puts the same options in @debuggeeVMOptions 
 as in -javaoptions when launching the JDI tests.
 
 I am not quite sure about the difference between -vmoptions and 
 -javaoptions. It seems both are used to change the options of the JVM 
 running the test. Because of this I pick up both values and forward them to 
 the launching of the debuggee JVM. However, I can't see any other tests that 
 use TESTJAVAOPTS, they all seem to use TESTVMOPTS. The problem with that for 
 my case is that the test infrastructure uses -javaoptions instead of 
 -vmoptions.
 
 webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.00/
 bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6622468
 
 Thanks,
 /Staffan
 

Re: AsyncGetCallTrace java profiling

[Staffan Larsen]

I think this is your bug report: http://bugs.sun.com/view_bug.do?bug_id=8022893

I have updated Affected Versions to include 8 as well. The change will take a 
day or so to propagate.

/Staffan

On 26 aug 2013, at 12:08, Alexandre De Champeaux a...@quartetfs.com wrote:

 Hi,
 
 I was able to reproduce the bug running java 8 (build b103, and so hotspot 
 build 25.0-b45). So I would like to update the bug report to java 8. I don't 
 have access to it though. Should I post a new one?
 
 
 On Tue, Aug 13, 2013 at 2:13 PM, Alexandre De Champeaux a...@quartetfs.com 
 wrote:
 Ok thanks. I just posted a bug report to bugs.sun.com describing the issue 
 (id 9005974).
 
 
 On Tue, Aug 13, 2013 at 1:00 PM, Alan Bateman alan.bate...@oracle.com wrote:
 On 13/08/2013 09:11, Alexandre De Champeaux wrote:
 
 Hi all,
 
 I posted this message a few days ago in the discuss mailing list. This one 
 seems way more accurate though, so i am posting it again.
 
 Following his blog post 
 (http://jeremymanson.blogspot.fr/2013/07/lightweight-asynchronous-sampling.html),
  I have been trying to use the code Jeremy Manson proposes to use the 
 AsyncGetCallTrace function.
 Although it works smoothly on small examples, I see some impossible 
 stacktraces on real world projects, with complex interface structures. I 
 have posted a bug report that reproduces it and gives more details here : 
 https://code.google.com/p/lightweight-java-profiler/issues/detail?id=1
 
 I am trying to estimate if those stacktraces are sparse (seems to be so), 
 and so if a profiler that uses this feature will be reliable.
 
 Any known bugs / limitations of the AsyncGetCallTrace function?
 This function being undocumented, in what extent does it stays up to date?
 
 Thanks for your answers
 
 Alex
 When you say you've posted a bug report, does this mean to bugs.sun.com? 
 While not technically supported, it is known to be used by some products so 
 if there is an issue (and I remember this had a long bug tail originally) 
 then it would be good to track it.
 
 -Alan.
 
 

hg: jdk8/tl/jdk: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return null in some cases

[joel . franck]

Changeset: 6917c114b197
Author:jfranck
Date:  2013-08-26 13:38 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6917c114b197

8022343: j.l.Class.getAnnotatedSuperclass() doesn't return null in some cases
Reviewed-by: darcy, vromero, psandoz

! src/share/classes/java/lang/Class.java
! test/java/lang/annotation/TypeAnnotationReflection.java
+ test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java

Re: RFR(S): JDK-6622468 : TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

[David Holmes]

On 26/08/2013 9:27 PM, Staffan Larsen wrote:


On 26 aug 2013, at 13:03, David Holmes david.hol...@oracle.com wrote:


Staffan,

javaoptions will only be passed to the java invocation of the VM under test.

vmptions will be passed to all VM invocations including javac from the 
compile-jdk.


Thanks, that was what I thought. So if my VM under test wants to launch a new 
VM is would have to use javaoptions + vmoptions.


I would not expect so. Assuming compile-jdk and test-jdk are different I 
would expect your launched VM to perhaps, but not necessarily, want 
javaoptions only. There is no clear cut answer as sometimes the options 
coming in from the testsuite are not compatible with the options you 
need for the VM you are launching.




If your test-jdk and compile-jdk are the same then you will have trouble 
telling them apart :)

That aside I would have thought it quite reasonable for the debugger and 
debuggee VMs to need different options - hence the debuggeeVMOptions.


Do you have an example where this would be necessary?


Not off hand. I do recall past bugs/test-issues where the wrong options 
were being passed though.


David


Thanks,
/Staffan



David

On 23/08/2013 9:26 PM, Staffan Larsen wrote:

The JDI tests have some quite arcane way of sending command line options to the 
debuggee. Options have to be put into a file called @debuggeeVMOptions before 
invoking jtreg. This was apparently implemented before there was a way in jtreg 
to set -vmoptions/-javaoptions.

I'd like to remove this crufty code and instead use the value of 
-vmoptions/-javaoptions when launching the debuggee. This would make it a lot 
simpler and more consistent to launch these tests.

The current test infrastructure puts the same options in @debuggeeVMOptions as 
in -javaoptions when launching the JDI tests.

I am not quite sure about the difference between -vmoptions and -javaoptions. 
It seems both are used to change the options of the JVM running the test. 
Because of this I pick up both values and forward them to the launching of the 
debuggee JVM. However, I can't see any other tests that use TESTJAVAOPTS, they 
all seem to use TESTVMOPTS. The problem with that for my case is that the test 
infrastructure uses -javaoptions instead of -vmoptions.

webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.00/
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6622468

Thanks,
/Staffan

Re: RFR(S): JDK-6622468 : TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

[Staffan Larsen]

On 26 aug 2013, at 14:08, David Holmes david.hol...@oracle.com wrote:

 On 26/08/2013 9:27 PM, Staffan Larsen wrote:
 
 On 26 aug 2013, at 13:03, David Holmes david.hol...@oracle.com wrote:
 
 Staffan,
 
 javaoptions will only be passed to the java invocation of the VM under test.
 
 vmptions will be passed to all VM invocations including javac from the 
 compile-jdk.
 
 Thanks, that was what I thought. So if my VM under test wants to launch a 
 new VM is would have to use javaoptions + vmoptions.
 
 I would not expect so. Assuming compile-jdk and test-jdk are different I 
 would expect your launched VM to perhaps, but not necessarily, want 
 javaoptions only.

But vmoptions will also be sent to the VM under test, right? So regardless of 
compile-jdk and test-jdk being the same or not, the VM under test will be sent 
both vmoptions and javaoptions.

 There is no clear cut answer as sometimes the options coming in from the 
 testsuite are not compatible with the options you need for the VM you are 
 launching.
 
 
 If your test-jdk and compile-jdk are the same then you will have trouble 
 telling them apart :)
 
 That aside I would have thought it quite reasonable for the debugger and 
 debuggee VMs to need different options - hence the debuggeeVMOptions.
 
 Do you have an example where this would be necessary?
 
 Not off hand. I do recall past bugs/test-issues where the wrong options were 
 being passed though.

As far as I can tell, the current test infrastructure always sets 
@debuggeeVMOptions to the same thing as javaoptions. This results in both the 
debugger and the debuggee using the same options (exception, of course, when I 
try to reproduce a test failure and don't know about @debuggeeVMOptions in 
which case the debuggee is missing some options and I can't reproduce - which 
is what I am trying to solve by making this simpler.)

/Staffan



 
 David
 
 Thanks,
 /Staffan
 
 
 David
 
 On 23/08/2013 9:26 PM, Staffan Larsen wrote:
 The JDI tests have some quite arcane way of sending command line options 
 to the debuggee. Options have to be put into a file called 
 @debuggeeVMOptions before invoking jtreg. This was apparently implemented 
 before there was a way in jtreg to set -vmoptions/-javaoptions.
 
 I'd like to remove this crufty code and instead use the value of 
 -vmoptions/-javaoptions when launching the debuggee. This would make it a 
 lot simpler and more consistent to launch these tests.
 
 The current test infrastructure puts the same options in 
 @debuggeeVMOptions as in -javaoptions when launching the JDI tests.
 
 I am not quite sure about the difference between -vmoptions and 
 -javaoptions. It seems both are used to change the options of the JVM 
 running the test. Because of this I pick up both values and forward them 
 to the launching of the debuggee JVM. However, I can't see any other tests 
 that use TESTJAVAOPTS, they all seem to use TESTVMOPTS. The problem with 
 that for my case is that the test infrastructure uses -javaoptions instead 
 of -vmoptions.
 
 webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.00/
 bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6622468
 
 Thanks,
 /Staffan
 
 

Re: RFR(S): JDK-6622468 : TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

[Daniel D. Daugherty]

On 8/26/13 5:27 AM, Staffan Larsen wrote:

On 26 aug 2013, at 13:03, David Holmes david.hol...@oracle.com wrote:


If your test-jdk and compile-jdk are the same then you will have trouble 
telling them apart :)

That aside I would have thought it quite reasonable for the debugger and 
debuggee VMs to need different options - hence the debuggeeVMOptions.

Do you have an example where this would be necessary?


Yes. When testing slow configurations like fastdebug Server -Xcomp,
you really don't want both the debugger and debuggee VMs running in
that mode. If you execute the test suites that way, you'll get a lot
of timeouts because the debugger will take forever to drive the
debuggee.

In my personal test suite setup, I run debugger VMs with product Client
VM -Xmixed and the debuggee VMs with the target config. The only way to
do that is something like @debuggeeVMOptions. As far as I know, JavaTest/
JTREG doesn't directly support the concept of dual-VM tests (debugger/
debuggee or client/server) in so far as having a means of specifying
different options for the two VMs.


Dan




Thanks,
/Staffan


David

On 23/08/2013 9:26 PM, Staffan Larsen wrote:

The JDI tests have some quite arcane way of sending command line options to the 
debuggee. Options have to be put into a file called @debuggeeVMOptions before 
invoking jtreg. This was apparently implemented before there was a way in jtreg 
to set -vmoptions/-javaoptions.

I'd like to remove this crufty code and instead use the value of 
-vmoptions/-javaoptions when launching the debuggee. This would make it a lot 
simpler and more consistent to launch these tests.

The current test infrastructure puts the same options in @debuggeeVMOptions as 
in -javaoptions when launching the JDI tests.

I am not quite sure about the difference between -vmoptions and -javaoptions. 
It seems both are used to change the options of the JVM running the test. 
Because of this I pick up both values and forward them to the launching of the 
debuggee JVM. However, I can't see any other tests that use TESTJAVAOPTS, they 
all seem to use TESTVMOPTS. The problem with that for my case is that the test 
infrastructure uses -javaoptions instead of -vmoptions.

webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.00/
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6622468

Thanks,
/Staffan

hg: hsx/hotspot-rt/hotspot: 8022683: JNI GetStringUTFChars should return NULL on allocation failure not abort the VM

[mikael . gerdin]

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 
GetPrimitiveTypeArrayElements family of functions.
Reviewed-by: dholmes, coleenp

! src/share/vm/memory/allocation.hpp
! src/share/vm/prims/jni.cpp

Re: RFR(S): JDK-6622468 : TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

[Staffan Larsen]

So if we really want to be able to use different options for the debugger and 
the debuggee, then a solution would be a separate property that contains the 
options to send to the debuggee (as proposed in the original bug report). 
Something like:

 jtreg  -javaoption:'-Djdi.debuggee.VMoptions=-server -Xcomp'

and then the debugger would make sure to include this when launching the 
debuggee. This would still be better than the @debuggeeVMOptions solution. A 
little tricker to parse in shell based tests, though.

/Staffan

On 26 aug 2013, at 15:48, Daniel D. Daugherty daniel.daughe...@oracle.com 
wrote:

 On 8/26/13 5:27 AM, Staffan Larsen wrote:
 On 26 aug 2013, at 13:03, David Holmes david.hol...@oracle.com wrote:
 
 If your test-jdk and compile-jdk are the same then you will have trouble 
 telling them apart :)
 
 That aside I would have thought it quite reasonable for the debugger and 
 debuggee VMs to need different options - hence the debuggeeVMOptions.
 Do you have an example where this would be necessary?
 
 Yes. When testing slow configurations like fastdebug Server -Xcomp,
 you really don't want both the debugger and debuggee VMs running in
 that mode. If you execute the test suites that way, you'll get a lot
 of timeouts because the debugger will take forever to drive the
 debuggee.
 
 In my personal test suite setup, I run debugger VMs with product Client
 VM -Xmixed and the debuggee VMs with the target config. The only way to
 do that is something like @debuggeeVMOptions. As far as I know, JavaTest/
 JTREG doesn't directly support the concept of dual-VM tests (debugger/
 debuggee or client/server) in so far as having a means of specifying
 different options for the two VMs.
 
 
 Dan
 
 
 
 Thanks,
 /Staffan
 
 David
 
 On 23/08/2013 9:26 PM, Staffan Larsen wrote:
 The JDI tests have some quite arcane way of sending command line options 
 to the debuggee. Options have to be put into a file called 
 @debuggeeVMOptions before invoking jtreg. This was apparently implemented 
 before there was a way in jtreg to set -vmoptions/-javaoptions.
 
 I'd like to remove this crufty code and instead use the value of 
 -vmoptions/-javaoptions when launching the debuggee. This would make it a 
 lot simpler and more consistent to launch these tests.
 
 The current test infrastructure puts the same options in 
 @debuggeeVMOptions as in -javaoptions when launching the JDI tests.
 
 I am not quite sure about the difference between -vmoptions and 
 -javaoptions. It seems both are used to change the options of the JVM 
 running the test. Because of this I pick up both values and forward them 
 to the launching of the debuggee JVM. However, I can't see any other tests 
 that use TESTJAVAOPTS, they all seem to use TESTVMOPTS. The problem with 
 that for my case is that the test infrastructure uses -javaoptions instead 
 of -vmoptions.
 
 webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.00/
 bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6622468
 
 Thanks,
 /Staffan
 
 

hg: jdk8/tl/jdk: 8023234: StampedLock serializes readers on writer unlock

[paul . sandoz]

Changeset: 8a36fc7f494c
Author:shade
Date:  2013-08-26 17:50 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a36fc7f494c

8023234: StampedLock serializes readers on writer unlock
Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock
Reviewed-by: martin, shade
Contributed-by: Doug Lea d...@cs.oswego.edu

! src/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java

hg: jdk8/tl/jdk: 8011944: Sort fails with ArrayIndexOutOfBoundsException

[roger . riggs]

Changeset: 07585a2483fa
Author:rriggs
Date:  2013-08-26 11:46 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07585a2483fa

8011944: Sort fails with ArrayIndexOutOfBoundsException
Summary: Increase the size of pending stack and add test cases
Reviewed-by: alanb

! src/share/classes/java/util/ComparableTimSort.java
! src/share/classes/java/util/TimSort.java
+ test/java/util/Arrays/TimSortStackSize.java

Re: Request for review:8023477: Invalid CP index when reading ConstantPool

[Jiangli Zhou]

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.z...@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.z...@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.spit...@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.spit...@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

Re: RFR: 7164841: Improvements to the GC log file rotation

[Yumin Qi]

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-712). 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 datetime to 
file_name w/ +UseGCLogFileRotation; if not, we won't have datetime 
info.


I think it would be useful to let both cases (w/ and w/o 
UseGCLogFileRotation) have datetime 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 + pidpid + 
-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-pidpid--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 

Re: AsyncGetCallTrace java profiling

[serguei.spit...@oracle.com]

Alexandre,

Thank you for the information and details.
I've added your it to the JBS version of 8022893.

Thanks,
Serguei

On 8/26/13 4:30 AM, Staffan Larsen wrote:
I think this is your bug report: 
http://bugs.sun.com/view_bug.do?bug_id=8022893


I have updated Affected Versions to include 8 as well. The change will 
take a day or so to propagate.


/Staffan

On 26 aug 2013, at 12:08, Alexandre De Champeaux a...@quartetfs.com 
mailto:a...@quartetfs.com wrote:



Hi,

I was able to reproduce the bug running java 8 (build b103, and so 
hotspot build 25.0-b45). So I would like to update the bug report to 
java 8. I don't have access to it though. Should I post a new one?



On Tue, Aug 13, 2013 at 2:13 PM, Alexandre De Champeaux 
a...@quartetfs.com mailto:a...@quartetfs.com wrote:


Ok thanks. I just posted a bug report to bugs.sun.com
http://bugs.sun.com/ describing the issue (id 9005974).


On Tue, Aug 13, 2013 at 1:00 PM, Alan Bateman
alan.bate...@oracle.com mailto:alan.bate...@oracle.com wrote:

On 13/08/2013 09:11, Alexandre De Champeaux wrote:

Hi all,

I posted this message a few days ago in the discuss mailing
list. This one seems way more accurate though, so i am
posting it again.

Following his blog post

(http://jeremymanson.blogspot.fr/2013/07/lightweight-asynchronous-sampling.html),
I have been trying to use the code Jeremy Manson proposes to
use the AsyncGetCallTrace function.
Although it works smoothly on small examples, I see some
impossible stacktraces on real world projects, with complex
interface structures. I have posted a bug report that
reproduces it and gives more details here :
https://code.google.com/p/lightweight-java-profiler/issues/detail?id=1

I am trying to estimate if those stacktraces are sparse
(seems to be so), and so if a profiler that uses this
feature will be reliable.

Any known bugs / limitations of the AsyncGetCallTrace function?
This function being undocumented, in what extent does it
stays up to date?

Thanks for your answers

Alex

When you say you've posted a bug report, does this mean to
bugs.sun.com http://bugs.sun.com/? While not technically
supported, it is known to be used by some products so if
there is an issue (and I remember this had a long bug tail
originally) then it would be good to track it.

-Alan.

hg: jdk8/tl/jdk: 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions

[sean . coffey]

Changeset: 92a66af7f834
Author:igerasim
Date:  2013-08-26 18:26 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92a66af7f834

8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions
Reviewed-by: alanb, chegar

! src/share/classes/java/lang/AbstractStringBuilder.java

Re: jstack can't attach to JVM (OS X)

[Martin Traverso]

Great! Thanks for the explanation.

Just curious, why does running jstack at least once before the code reaches
that method call prevent the problem from happening at all?

Martin


On Mon, Aug 26, 2013 at 5:31 AM, Staffan Larsen
staffan.lar...@oracle.comwrote:

 Here is what's happening:

 - The VM sets the signal mask for all threads (except the internal
 VMThread) to mask out SIGQUIT using pthread_sigmask(). So the process will
 still respond to SIGQUIT, but only one thread.
 - The verifier code calls setjmp() to save the calling context. On OS X
 this also saves the signal mask.
 - The example code causes a verification error somewhere which causes the
 verifier to call longjmp().
 - longjmp will restore the signal mask using sigprocmask() which sets the
 signal mask for the _process_.
 - Now the process has a signal mask that masks out SIGQUIT and attach
 stops working.

 This only happens on OS X because setjmp/longjmp does not save and restore
 the signal mask on other platforms. There are functions _setjmp/_longjmp on
 OS X to skip the signal mask save/restore and I think this is what we need
 to use in the verifier (also need to check other uses of setjmp/longjmp in
 the JDK).

 I have filed bug 8023720 for this.

 Thanks again for the report and reproducer.

 /Staffan




 On 23 aug 2013, at 14:44, Staffan Larsen staffan.lar...@oracle.com
 wrote:

 Thanks for the excellent bugreport!

 I've had a quick look today but haven't yet figured out what the problem
 is. What happens is that somehow the process becomes immune to the SIGQUIT
 that jstack sends to it when it wants to attach. Instead of running jstack,
 one can also do kill -QUIT pid and with this code no thread stacks are
 printed (as they normally will be).

 I'll continue looking,
 /Staffan

 On 23 aug 2013, at 07:20, Martin Traverso mtrave...@gmail.com wrote:

 I have a program that causes jstack and jcmd to fail to attach to the JVM
 on OS X. Unfortunately, it uses a third-party library, so I'm not sure
 what's the magic incantation that causes this to happen.

 I wrote a small test case using this library that reproduces the problem.
 You can find the code here: https://github.com/martint/jstackissue.

 I've seen the problem on both 1.7.0_25-b15 and 1.8.0-ea-b100 on OS X, but
 not on Java 6. It doesn't seem to happen on Linux, either.

 One interesting data point is that if I run jstack before the code makes
 the call to the library, it works, and continues to work even after that
 call is complete. On the other hand, if run jstack for the first time
 *after* the call to the library, it won't work at all.

 Any ideas?

 Thanks!
 Martin

hg: jdk8/tl: 8023491: Remove target names from test/Makefile and defer to sub-repo makefiles.

[mike . duigou]

Changeset: f643fee2b40f
Author:mduigou
Date:  2013-08-26 10:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/f643fee2b40f

8023491: Remove target names from test/Makefile and defer to sub-repo makefiles.
Reviewed-by: erikj

! common/makefiles/Main.gmk
! test/Makefile

hg: jdk8/tl/langtools: 8023701: Fix badly named test

[jonathan . gibbons]

Changeset: 60f156c653d3
Author:jjg
Date:  2013-08-26 11:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/60f156c653d3

8023701: Fix badly named test
Reviewed-by: bpatel

- test/com/sun/javadoc/testNavagation/TestNavagation.java
- test/com/sun/javadoc/testNavagation/pkg/A.java
- test/com/sun/javadoc/testNavagation/pkg/C.java
- test/com/sun/javadoc/testNavagation/pkg/E.java
- test/com/sun/javadoc/testNavagation/pkg/I.java
+ test/com/sun/javadoc/testNavigation/TestNavigation.java
+ test/com/sun/javadoc/testNavigation/pkg/A.java
+ test/com/sun/javadoc/testNavigation/pkg/C.java
+ test/com/sun/javadoc/testNavigation/pkg/E.java
+ test/com/sun/javadoc/testNavigation/pkg/I.java

hg: jdk8/tl/jdk: 8020292: j.u.SplittableRandom

[paul . sandoz]

Changeset: 5ce9025c9e1a
Author:psandoz
Date:  2013-08-26 22:55 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ce9025c9e1a

8020292: j.u.SplittableRandom
Reviewed-by: mduigou
Contributed-by: Guy Steele guy.ste...@oracle.com, Doug Lea 
d...@cs.oswego.edu, Brian Goetz brian.go...@oracle.com, Paul Sandoz 
paul.san...@oracle.com

+ src/share/classes/java/util/SplittableRandom.java
+ test/java/util/SplittableRandom/SplittableRandomTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java

hg: jdk8/tl/jdk: 8023681: Fix raw type warning caused by Sink

[henry . jen]

Changeset: 35c1609d9488
Author:henryjen
Date:  2013-08-09 09:05 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35c1609d9488

8023681: Fix raw type warning caused by Sink
Reviewed-by: mduigou, briangoetz

! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DistinctOps.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/ReferencePipeline.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SliceOps.java
! src/share/classes/java/util/stream/SortedOps.java

Re: AsyncGetCallTrace java profiling

[serguei.spit...@oracle.com]

On 8/26/13 10:12 AM, serguei.spit...@oracle.com wrote:

Alexandre,

Thank you for the information and details.
I've added your it to the JBS version of 8022893.


The details from this link and the link itself were already in that bug 
report 8022893:

https://code.google.com/p/lightweight-java-profiler/issues/detail?id=1


Thanks,
Serguei



Thanks,
Serguei

On 8/26/13 4:30 AM, Staffan Larsen wrote:
I think this is your bug report: 
http://bugs.sun.com/view_bug.do?bug_id=8022893


I have updated Affected Versions to include 8 as well. The change 
will take a day or so to propagate.


/Staffan

On 26 aug 2013, at 12:08, Alexandre De Champeaux a...@quartetfs.com 
mailto:a...@quartetfs.com wrote:



Hi,

I was able to reproduce the bug running java 8 (build b103, and so 
hotspot build 25.0-b45). So I would like to update the bug report to 
java 8. I don't have access to it though. Should I post a new one?



On Tue, Aug 13, 2013 at 2:13 PM, Alexandre De Champeaux 
a...@quartetfs.com mailto:a...@quartetfs.com wrote:


Ok thanks. I just posted a bug report to bugs.sun.com
http://bugs.sun.com/ describing the issue (id 9005974).


On Tue, Aug 13, 2013 at 1:00 PM, Alan Bateman
alan.bate...@oracle.com mailto:alan.bate...@oracle.com wrote:

On 13/08/2013 09:11, Alexandre De Champeaux wrote:

Hi all,

I posted this message a few days ago in the discuss mailing
list. This one seems way more accurate though, so i am
posting it again.

Following his blog post

(http://jeremymanson.blogspot.fr/2013/07/lightweight-asynchronous-sampling.html),
I have been trying to use the code Jeremy Manson proposes
to use the AsyncGetCallTrace function.
Although it works smoothly on small examples, I see some
impossible stacktraces on real world projects, with complex
interface structures. I have posted a bug report that
reproduces it and gives more details here :
https://code.google.com/p/lightweight-java-profiler/issues/detail?id=1

I am trying to estimate if those stacktraces are sparse
(seems to be so), and so if a profiler that uses this
feature will be reliable.

Any known bugs / limitations of the AsyncGetCallTrace function?
This function being undocumented, in what extent does it
stays up to date?

Thanks for your answers

Alex

When you say you've posted a bug report, does this mean to
bugs.sun.com http://bugs.sun.com/? While not technically
supported, it is known to be used by some products so if
there is an issue (and I remember this had a long bug tail
originally) then it would be good to track it.

-Alan.

hg: hsx/hotspot-rt/hotspot: 2 new changesets

[stefan . karlsson]

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

hg: jdk8/tl/langtools: 8023768: Use the unannotatedType in cyclicity checks.

[jonathan . gibbons]

Changeset: 7bf6313e1ced
Author:jjg
Date:  2013-08-26 15:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7bf6313e1ced

8023768: Use the unannotatedType in cyclicity checks.
Reviewed-by: jjg
Contributed-by: wdi...@gmail.com

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java

Re: AsyncGetCallTrace java profiling

[serguei.spit...@oracle.com]

On 8/26/13 10:12 AM, serguei.spit...@oracle.com wrote:

Alexandre,

Thank you for the information and details.
I've added your it to the JBS version of 8022893.


The details from this link and the link itself were already in that bug 
report 8022893:

https://code.google.com/p/lightweight-java-profiler/issues/detail?id=1


Thanks,
Serguei



Thanks,
Serguei

On 8/26/13 4:30 AM, Staffan Larsen wrote:
I think this is your bug report: 
http://bugs.sun.com/view_bug.do?bug_id=8022893


I have updated Affected Versions to include 8 as well. The change 
will take a day or so to propagate.


/Staffan

On 26 aug 2013, at 12:08, Alexandre De Champeaux a...@quartetfs.com 
mailto:a...@quartetfs.com wrote:



Hi,

I was able to reproduce the bug running java 8 (build b103, and so 
hotspot build 25.0-b45). So I would like to update the bug report to 
java 8. I don't have access to it though. Should I post a new one?



On Tue, Aug 13, 2013 at 2:13 PM, Alexandre De Champeaux 
a...@quartetfs.com mailto:a...@quartetfs.com wrote:


Ok thanks. I just posted a bug report to bugs.sun.com
http://bugs.sun.com/ describing the issue (id 9005974).


On Tue, Aug 13, 2013 at 1:00 PM, Alan Bateman
alan.bate...@oracle.com mailto:alan.bate...@oracle.com wrote:

On 13/08/2013 09:11, Alexandre De Champeaux wrote:

Hi all,

I posted this message a few days ago in the discuss mailing
list. This one seems way more accurate though, so i am
posting it again.

Following his blog post

(http://jeremymanson.blogspot.fr/2013/07/lightweight-asynchronous-sampling.html),
I have been trying to use the code Jeremy Manson proposes
to use the AsyncGetCallTrace function.
Although it works smoothly on small examples, I see some
impossible stacktraces on real world projects, with complex
interface structures. I have posted a bug report that
reproduces it and gives more details here :
https://code.google.com/p/lightweight-java-profiler/issues/detail?id=1

I am trying to estimate if those stacktraces are sparse
(seems to be so), and so if a profiler that uses this
feature will be reliable.

Any known bugs / limitations of the AsyncGetCallTrace function?
This function being undocumented, in what extent does it
stays up to date?

Thanks for your answers

Alex

When you say you've posted a bug report, does this mean to
bugs.sun.com http://bugs.sun.com/? While not technically
supported, it is known to be used by some products so if
there is an issue (and I remember this had a long bug tail
originally) then it would be good to track it.

-Alan.

Re: jstack can't attach to JVM (OS X)

[David Holmes]

On 26/08/2013 10:31 PM, Staffan Larsen wrote:

Here is what's happening:

- The VM sets the signal mask for all threads (except the internal
VMThread) to mask out SIGQUIT using pthread_sigmask(). So the process
will still respond to SIGQUIT, but only one thread.
- The verifier code calls setjmp() to save the calling context. On OS X
this also saves the signal mask.
- The example code causes a verification error somewhere which causes
the verifier to call longjmp().
- longjmp will restore the signal mask using sigprocmask() which sets
the signal mask for the _process_.


Wow! Talk about broken! :( If you are going to provide system calls that 
look like POSIX then they should implement POSIX semantics!


The use of the sigprocmask() function is unspecified in a 
multi-threaded process.


http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigprocmask.html

And guess what:

https://developer.apple.com/library/ios/documentation/system/conceptual/manpages_iphoneos/man2/sigprocmask.2.html#//apple_ref/doc/man/2/sigprocmask

   The sigprocmask() function call is expected to conform to IEEE Std
 1003.1-1988 (``POSIX.1'').

Maybe they need to bring their operating system into the 21st century! 
Sheesh!


David
-


- Now the process has a signal mask that masks out SIGQUIT and attach
stops working.

This only happens on OS X because setjmp/longjmp does not save and
restore the signal mask on other platforms. There are functions
_setjmp/_longjmp on OS X to skip the signal mask save/restore and I
think this is what we need to use in the verifier (also need to check
other uses of setjmp/longjmp in the JDK).

I have filed bug 8023720 for this.

Thanks again for the report and reproducer.

/Staffan




On 23 aug 2013, at 14:44, Staffan Larsen staffan.lar...@oracle.com
mailto:staffan.lar...@oracle.com wrote:


Thanks for the excellent bugreport!

I've had a quick look today but haven't yet figured out what the
problem is. What happens is that somehow the process becomes immune to
the SIGQUIT that jstack sends to it when it wants to attach. Instead
of running jstack, one can also do kill -QUIT pid and with this
code no thread stacks are printed (as they normally will be).

I'll continue looking,
/Staffan

On 23 aug 2013, at 07:20, Martin Traverso mtrave...@gmail.com
mailto:mtrave...@gmail.com wrote:


I have a program that causes jstack and jcmd to fail to attach to the
JVM on OS X. Unfortunately, it uses a third-party library, so I'm not
sure what's the magic incantation that causes this to happen.

I wrote a small test case using this library that reproduces the
problem. You can find the code here:
https://github.com/martint/jstackissue.

I've seen the problem on both 1.7.0_25-b15 and 1.8.0-ea-b100 on OS X,
but not on Java 6. It doesn't seem to happen on Linux, either.

One interesting data point is that if I run jstack before the code
makes the call to the library, it works, and continues to work even
after that call is complete. On the other hand, if run jstack for the
first time *after* the call to the library, it won't work at all.

Any ideas?

Thanks!
Martin

hg: jdk8/tl/jaxws: 3 new changesets

[lana . steuck]

Changeset: 42211ab0ab1c
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/42211ab0ab1c

Added tag jdk8-b103 for changeset 6cdc6ed98780

! .hgtags

Changeset: 88390df7ed2c
Author:cl
Date:  2013-08-22 09:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88390df7ed2c

Added tag jdk8-b104 for changeset 42211ab0ab1c

! .hgtags

Changeset: 533c1032337c
Author:lana
Date:  2013-08-26 14:50 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/533c1032337c

Merge

hg: jdk8/tl/jaxp: 4 new changesets

[lana . steuck]

Changeset: a22fe9bd01e6
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a22fe9bd01e6

Added tag jdk8-b103 for changeset b1ceab582fc6

! .hgtags

Changeset: af28b93bfb6f
Author:cl
Date:  2013-08-22 09:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/af28b93bfb6f

Added tag jdk8-b104 for changeset a22fe9bd01e6

! .hgtags

Changeset: d4d6422ec564
Author:lana
Date:  2013-08-20 17:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d4d6422ec564

Merge


Changeset: 09a46ec11f88
Author:lana
Date:  2013-08-23 14:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/09a46ec11f88

Merge

hg: jdk8/tl/nashorn: 5 new changesets

[lana . steuck]

Changeset: afc100513451
Author:cl
Date:  2013-08-15 09:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/afc100513451

Added tag jdk8-b103 for changeset 414203de4374

! .hgtags

Changeset: 74244f43c577
Author:cl
Date:  2013-08-22 09:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/74244f43c577

Added tag jdk8-b104 for changeset afc100513451

! .hgtags

Changeset: 1f2394beecf7
Author:lana
Date:  2013-08-20 17:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/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/jdk8/tl/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: a18f92a0a910
Author:lana
Date:  2013-08-26 14:54 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a18f92a0a910

Merge

hg: jdk8/tl/corba: 2 new changesets

[lana . steuck]

Changeset: d411c60a8c2f
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/d411c60a8c2f

Added tag jdk8-b103 for changeset 49c4a777fdfd

! .hgtags

Changeset: 4e38de7c767e
Author:cl
Date:  2013-08-22 09:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/4e38de7c767e

Added tag jdk8-b104 for changeset d411c60a8c2f

! .hgtags

hg: jdk8/tl/langtools: 6 new changesets

[lana . steuck]

Changeset: dd4a00c220c6
Author:cl
Date:  2013-08-15 09:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dd4a00c220c6

Added tag jdk8-b103 for changeset 76cfe7c61f25

! .hgtags

Changeset: f2ee3a4e7927
Author:cl
Date:  2013-08-22 09:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f2ee3a4e7927

Added tag jdk8-b104 for changeset dd4a00c220c6

! .hgtags

Changeset: b59a0b4675c9
Author:lana
Date:  2013-08-20 17:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/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/jdk8/tl/langtools/rev/375834b5cf08

Merge

- 
test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java

Changeset: 00ca54ceca1b
Author:lana
Date:  2013-08-26 14:54 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/00ca54ceca1b

Merge


Changeset: cc3fb73f5e08
Author:lana
Date:  2013-08-26 22:18 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc3fb73f5e08

Merge

hg: jdk8/tl: 9 new changesets

[lana . steuck]

Changeset: ceefd94ef326
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/ceefd94ef326

Added tag jdk8-b103 for changeset b7e64be81c8a

! .hgtags

Changeset: 4fb877dfe5c4
Author:erikj
Date:  2013-08-15 17:14 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/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/jdk8/tl/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/jdk8/tl/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/jdk8/tl/rev/96c1b9b7524b

Merge


Changeset: c3b5197f2851
Author:cl
Date:  2013-08-22 09:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/c3b5197f2851

Added tag jdk8-b104 for changeset 96c1b9b7524b

! .hgtags

Changeset: e8a3edda1f60
Author:lana
Date:  2013-08-20 17:40 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/e8a3edda1f60

Merge


Changeset: 056398db9dcb
Author:lana
Date:  2013-08-23 14:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/056398db9dcb

Merge

! common/autoconf/generated-configure.sh

Changeset: 163091288aeb
Author:lana
Date:  2013-08-26 14:49 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/163091288aeb

Merge

! common/makefiles/Main.gmk

hg: jdk8/tl/hotspot: 32 new changesets

[lana . steuck]

Changeset: 0bbd1c775bef
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0bbd1c775bef

Added tag jdk8-b103 for changeset 6f9be7f87b96

! .hgtags

Changeset: 39127bb12d32
Author:amurillo
Date:  2013-08-09 01:39 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39127bb12d32

8022688: new hotspot build - hs25-b46
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ca0165daa6ec
Author:sspitsyn
Date:  2013-08-06 16:33 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/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.spit...@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/jdk8/tl/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/jdk8/tl/hotspot/rev/196aa14f9f29

Merge


Changeset: 195ff07bc7f6
Author:dsamersoff
Date:  2013-08-07 19:02 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/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: rednaxel...@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/jdk8/tl/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/jdk8/tl/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/jdk8/tl/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...@oracle.com

! test/runtime/7107135/Test7107135.sh

Changeset: 6222a021d582
Author:minqi
Date:  2013-08-08 20:13 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6222a021d582

Merge


Changeset: 98aa538fd97e
Author:mikael
Date:  2013-08-09 09:51 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/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/jdk8/tl/hotspot/rev/ed7c17e7d45b

Merge


Changeset: 7b03590c334b
Author:dcubed
Date:  2013-08-09 15:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b03590c334b

Merge


Changeset: bd0e82136b03
Author:iklam
Date:  2013-08-10 10:56 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd0e82136b03

8022740: Visual 2008 IDE build is broken
Summary: Fixed project generation code, and added warning to 

hg: jdk8/tl/jdk: 23 new changesets

[lana . steuck]

Changeset: f1d8d15bfcb5
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1d8d15bfcb5

Added tag jdk8-b103 for changeset e0f6039c0290

! .hgtags

Changeset: c982f579b67e
Author:cl
Date:  2013-08-22 09:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c982f579b67e

Added tag jdk8-b104 for changeset f1d8d15bfcb5

! .hgtags

Changeset: 2722f4000b65
Author:jgodinez
Date:  2013-08-15 11:56 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/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/jdk8/tl/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/jdk8/tl/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/jdk8/tl/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/jdk8/tl/jdk/rev/64be71ae6185

Merge


Changeset: 903a279f1fce
Author:ant
Date:  2013-08-09 05:20 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/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/jdk8/tl/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/jdk8/tl/jdk/rev/4702ab74b70a

7027045: (doc) java/awt/Window.java has several typos in javadoc
Reviewed-by: art, serb
Contributed-by: konstantin.peri...@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/jdk8/tl/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/jdk8/tl/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/jdk8/tl/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/jdk8/tl/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/jdk8/tl/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/jdk8/tl/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/jdk8/tl/jdk/rev/e3316cd6ca47

8006085: [findbugs] a warning on