From vladimir.kozlov at oracle.com  Wed Dec  1 12:30:08 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 01 Dec 2010 12:30:08 -0800
Subject: [Fwd: Re: Request for Review (XS): 6704010: Internal
	Error(src/share/vm/interpreter/interpreterRuntime.cpp:1106)]
Message-ID: <4CF6B050.6050900@oracle.com>

Sending to runtime alias since it is RT bug.

-------- Original Message --------
Subject: Re: Request for Review (XS): 6704010: Internal Error	(src/share/vm/interpreter/interpreterRuntime.cpp:1106)
Date: Wed, 1 Dec 2010 19:44:40 +0100
From: Volker Simonis <volker.simonis at gmail.com>
To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>

http://www.progdoc.de/webrev/6704010/

This problem occurs very rarely and it is therefore hardly possible to
reliably reproduce it. However after looking at it for a while I think
I found the cause of the problem:

The SignatureHandlerLibrary class uses two static GrowableArrays,
'_handlers' and '_fingerprints', to store method fingerprints along
with their corresponding signature handlers. But GrowableArrays are
are NOT synchronized in any way if accessed from multiple threads. To
avoid races it is therefore necessary to synchronize different threads
which access the same GrowableArray. This is done for most of the code
in 'SignatureHandlerLibrary::add()' which is protected by 'MutexLocker
mu(SignatureHandlerLibrary_lock)'.

However the assertion at the end of the method is outside the scope of
this MutexLocker which can lead to an illegal view on the
corresponding GrowableArray data structures. Here'S what may happen in
detail:

  -thread one enters the section protected by the MutexLocker and adds
another fingerprint/handler to the growable arrays by calling
'GrowableArray::append()'. This can lead to an implicit call to
'GrowableArray::grow()' if the arrays size exhausted. In the 'grow()'
method a new data array will be allocated, the contents of the old
array will be copied into the new one and then (1) the storage
occupied by the old array will be freed and (2) the address of the new
storage will be assigned to the internal data pointer. Between (1) and
(2) there's a small (like once every six month or so:) chance that the
thread will be unscheduled and another thread is allocating the memory
which has just been freed.

- thread two is just in the assertion code and trying to query the
GrowableArrays '_handlers' and '_fingerprints' by calling
'GrowableArray::find()'. If this happens right in the interval
between the points (1) and (2) described above, the 'find()' method
may return incorrect results which can spuriously trigger the
assertion.

Fixing this can be easily done by enclosing the assertion into a
region which is protected by the same Mutex like the main body of
'SignatureHandlerLibrary::add()'.

As I wrote, I couldn't reproduce this in the HostSpot, so no
regression test. I was however able to reproduce the described
scenario with a standalone GrowableArray class and a small test
program consisting of one writer thread which appends a constant value
to a GrowableArray and ten reader threads which are constantly trying
to find that special value in the array on a dual core x86_64 Linux
box.

As a last side note, the problem could also be made even more
unlikely, by changing the implementation of   'GrowableArray::grow()'
from:

template<class E> void GrowableArray<E>::grow(int j) {
     int old_max = _max;
     ...
     if (on_C_heap() && _data != NULL) {
       FreeHeap(_data);
     }
     _data = newData;
}

to:

template<class E> void GrowableArray<E>::grow(int j) {
     int old_max = _max;
     ...
     _old_data = _data;
     _data = newData;
     if (on_C_heap() && _old_data != NULL) {
       FreeHeap(_old_data);
     }
}

On the other hand that's still not 100% safe ('_data' is not volatile,
other memory models, ..) and I think GrowableArray is definitely not
intended for parallel access and therefore such a change may
unnecessarily hide other problems where this precondition is violated.
So maybe nulling out the '_data' array before freeing it may be a good
idea in the debug build to catch such errors!

Regards,
Volker

From bengt.rutisson at oracle.com  Wed Dec  1 09:19:11 2010
From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com)
Date: Wed, 01 Dec 2010 17:19:11 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7003456: ADLC files not correctly
	generated on Windows
Message-ID: <20101201171913.4C7A047FDE@hg.openjdk.java.net>

Changeset: 01c0559441c8
Author:    brutisso
Date:      2010-12-01 03:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/01c0559441c8

7003456: ADLC files not correctly generated on Windows
Summary: Added target architecture parameters to make ADLC build properly
Reviewed-by: never, stefank

! make/windows/makefiles/adlc.make


From coleen.phillimore at oracle.com  Wed Dec  1 15:08:53 2010
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 01 Dec 2010 18:08:53 -0500
Subject: [Fwd: Re: Request for Review (XS): 6704010: Internal
	Error(src/share/vm/interpreter/interpreterRuntime.cpp:1106)]
In-Reply-To: <4CF6B050.6050900@oracle.com>
References: <4CF6B050.6050900@oracle.com>
Message-ID: <4CF6D585.3030300@oracle.com>

Volker,
This is great.  This was on my bug list.  It looks good to me and I'll 
be happy to push it for you.
Thanks!
Coleen

Vladimir Kozlov wrote:
> Sending to runtime alias since it is RT bug.
>
> -------- Original Message --------
> Subject: Re: Request for Review (XS): 6704010: Internal Error    
> (src/share/vm/interpreter/interpreterRuntime.cpp:1106)
> Date: Wed, 1 Dec 2010 19:44:40 +0100
> From: Volker Simonis <volker.simonis at gmail.com>
> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>
> http://www.progdoc.de/webrev/6704010/
>
> This problem occurs very rarely and it is therefore hardly possible to
> reliably reproduce it. However after looking at it for a while I think
> I found the cause of the problem:
>
> The SignatureHandlerLibrary class uses two static GrowableArrays,
> '_handlers' and '_fingerprints', to store method fingerprints along
> with their corresponding signature handlers. But GrowableArrays are
> are NOT synchronized in any way if accessed from multiple threads. To
> avoid races it is therefore necessary to synchronize different threads
> which access the same GrowableArray. This is done for most of the code
> in 'SignatureHandlerLibrary::add()' which is protected by 'MutexLocker
> mu(SignatureHandlerLibrary_lock)'.
>
> However the assertion at the end of the method is outside the scope of
> this MutexLocker which can lead to an illegal view on the
> corresponding GrowableArray data structures. Here'S what may happen in
> detail:
>
>  -thread one enters the section protected by the MutexLocker and adds
> another fingerprint/handler to the growable arrays by calling
> 'GrowableArray::append()'. This can lead to an implicit call to
> 'GrowableArray::grow()' if the arrays size exhausted. In the 'grow()'
> method a new data array will be allocated, the contents of the old
> array will be copied into the new one and then (1) the storage
> occupied by the old array will be freed and (2) the address of the new
> storage will be assigned to the internal data pointer. Between (1) and
> (2) there's a small (like once every six month or so:) chance that the
> thread will be unscheduled and another thread is allocating the memory
> which has just been freed.
>
> - thread two is just in the assertion code and trying to query the
> GrowableArrays '_handlers' and '_fingerprints' by calling
> 'GrowableArray::find()'. If this happens right in the interval
> between the points (1) and (2) described above, the 'find()' method
> may return incorrect results which can spuriously trigger the
> assertion.
>
> Fixing this can be easily done by enclosing the assertion into a
> region which is protected by the same Mutex like the main body of
> 'SignatureHandlerLibrary::add()'.
>
> As I wrote, I couldn't reproduce this in the HostSpot, so no
> regression test. I was however able to reproduce the described
> scenario with a standalone GrowableArray class and a small test
> program consisting of one writer thread which appends a constant value
> to a GrowableArray and ten reader threads which are constantly trying
> to find that special value in the array on a dual core x86_64 Linux
> box.
>
> As a last side note, the problem could also be made even more
> unlikely, by changing the implementation of   'GrowableArray::grow()'
> from:
>
> template<class E> void GrowableArray<E>::grow(int j) {
>     int old_max = _max;
>     ...
>     if (on_C_heap() && _data != NULL) {
>       FreeHeap(_data);
>     }
>     _data = newData;
> }
>
> to:
>
> template<class E> void GrowableArray<E>::grow(int j) {
>     int old_max = _max;
>     ...
>     _old_data = _data;
>     _data = newData;
>     if (on_C_heap() && _old_data != NULL) {
>       FreeHeap(_old_data);
>     }
> }
>
> On the other hand that's still not 100% safe ('_data' is not volatile,
> other memory models, ..) and I think GrowableArray is definitely not
> intended for parallel access and therefore such a change may
> unnecessarily hide other problems where this precondition is violated.
> So maybe nulling out the '_data' array before freeing it may be a good
> idea in the debug build to catch such errors!
>
> Regards,
> Volker

From coleen.phillimore at oracle.com  Wed Dec  1 18:13:15 2010
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 02 Dec 2010 02:13:15 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20101202021319.345C247FF7@hg.openjdk.java.net>

Changeset: 828eafbd85cc
Author:    ikrylov
Date:      2010-12-01 18:26 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/828eafbd85cc

6348631: remove the use of the HPI library from Hotspot
Summary: move functions from hpi library to hotspot, communicate with licensees and open source community, check jdk for dependency, file CCC request
Reviewed-by: coleenp, acorn, dsamersoff

! src/cpu/sparc/vm/depChecker_sparc.cpp
! src/cpu/x86/vm/depChecker_x86.cpp
! src/cpu/zero/vm/depChecker_zero.cpp
- src/os/linux/vm/hpi_linux.cpp
- src/os/linux/vm/hpi_linux.hpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.inline.hpp
- src/os/solaris/vm/hpi_solaris.cpp
- src/os/solaris/vm/hpi_solaris.hpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/os_solaris.inline.hpp
- src/os/windows/vm/hpi_windows.cpp
- src/os/windows/vm/hpi_windows.hpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.inline.hpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/memory/dump.cpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/precompiled.hpp
- src/share/vm/prims/hpi_imported.h
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/runtime/globals.hpp
- src/share/vm/runtime/hpi.cpp
- src/share/vm/runtime/hpi.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/osThread.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/ostream.cpp

Changeset: 3c205c4f1cda
Author:    coleenp
Date:      2010-12-01 18:32 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3c205c4f1cda

Merge

- src/os/linux/vm/hpi_linux.cpp
- src/os/linux/vm/hpi_linux.hpp
- src/os/solaris/vm/hpi_solaris.cpp
- src/os/solaris/vm/hpi_solaris.hpp
- src/os/windows/vm/hpi_windows.cpp
- src/os/windows/vm/hpi_windows.hpp
- src/share/vm/prims/hpi_imported.h
- src/share/vm/runtime/hpi.cpp
- src/share/vm/runtime/hpi.hpp


From David.Holmes at oracle.com  Wed Dec  1 18:46:43 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 02 Dec 2010 12:46:43 +1000
Subject: [Fwd: Re: Request for Review (XS): 6704010: Internal
	Error(src/share/vm/interpreter/interpreterRuntime.cpp:1106)]
In-Reply-To: <4CF6D585.3030300@oracle.com>
References: <4CF6B050.6050900@oracle.com> <4CF6D585.3030300@oracle.com>
Message-ID: <4CF70893.8080906@oracle.com>

Moving the assertion into a locked region may potentially cause a 
deadlock if the assertion fails and we go to fatal error handling. We'd 
need to check that the lock in question is not held in a nested fashion 
with another lock that might be needed in the fatal error path.

That said there are already potential deadlocks in fatal error handling 
with some debug/tracing options, so maybe that's a better trade-off than 
getting the false failure.

Just a thought.

David Holmes

Coleen Phillimore said the following on 12/02/10 09:08:
> Volker,
> This is great.  This was on my bug list.  It looks good to me and I'll 
> be happy to push it for you.
> Thanks!
> Coleen
> 
> Vladimir Kozlov wrote:
>> Sending to runtime alias since it is RT bug.
>>
>> -------- Original Message --------
>> Subject: Re: Request for Review (XS): 6704010: Internal Error    
>> (src/share/vm/interpreter/interpreterRuntime.cpp:1106)
>> Date: Wed, 1 Dec 2010 19:44:40 +0100
>> From: Volker Simonis <volker.simonis at gmail.com>
>> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>>
>> http://www.progdoc.de/webrev/6704010/
>>
>> This problem occurs very rarely and it is therefore hardly possible to
>> reliably reproduce it. However after looking at it for a while I think
>> I found the cause of the problem:
>>
>> The SignatureHandlerLibrary class uses two static GrowableArrays,
>> '_handlers' and '_fingerprints', to store method fingerprints along
>> with their corresponding signature handlers. But GrowableArrays are
>> are NOT synchronized in any way if accessed from multiple threads. To
>> avoid races it is therefore necessary to synchronize different threads
>> which access the same GrowableArray. This is done for most of the code
>> in 'SignatureHandlerLibrary::add()' which is protected by 'MutexLocker
>> mu(SignatureHandlerLibrary_lock)'.
>>
>> However the assertion at the end of the method is outside the scope of
>> this MutexLocker which can lead to an illegal view on the
>> corresponding GrowableArray data structures. Here'S what may happen in
>> detail:
>>
>>  -thread one enters the section protected by the MutexLocker and adds
>> another fingerprint/handler to the growable arrays by calling
>> 'GrowableArray::append()'. This can lead to an implicit call to
>> 'GrowableArray::grow()' if the arrays size exhausted. In the 'grow()'
>> method a new data array will be allocated, the contents of the old
>> array will be copied into the new one and then (1) the storage
>> occupied by the old array will be freed and (2) the address of the new
>> storage will be assigned to the internal data pointer. Between (1) and
>> (2) there's a small (like once every six month or so:) chance that the
>> thread will be unscheduled and another thread is allocating the memory
>> which has just been freed.
>>
>> - thread two is just in the assertion code and trying to query the
>> GrowableArrays '_handlers' and '_fingerprints' by calling
>> 'GrowableArray::find()'. If this happens right in the interval
>> between the points (1) and (2) described above, the 'find()' method
>> may return incorrect results which can spuriously trigger the
>> assertion.
>>
>> Fixing this can be easily done by enclosing the assertion into a
>> region which is protected by the same Mutex like the main body of
>> 'SignatureHandlerLibrary::add()'.
>>
>> As I wrote, I couldn't reproduce this in the HostSpot, so no
>> regression test. I was however able to reproduce the described
>> scenario with a standalone GrowableArray class and a small test
>> program consisting of one writer thread which appends a constant value
>> to a GrowableArray and ten reader threads which are constantly trying
>> to find that special value in the array on a dual core x86_64 Linux
>> box.
>>
>> As a last side note, the problem could also be made even more
>> unlikely, by changing the implementation of   'GrowableArray::grow()'
>> from:
>>
>> template<class E> void GrowableArray<E>::grow(int j) {
>>     int old_max = _max;
>>     ...
>>     if (on_C_heap() && _data != NULL) {
>>       FreeHeap(_data);
>>     }
>>     _data = newData;
>> }
>>
>> to:
>>
>> template<class E> void GrowableArray<E>::grow(int j) {
>>     int old_max = _max;
>>     ...
>>     _old_data = _data;
>>     _data = newData;
>>     if (on_C_heap() && _old_data != NULL) {
>>       FreeHeap(_old_data);
>>     }
>> }
>>
>> On the other hand that's still not 100% safe ('_data' is not volatile,
>> other memory models, ..) and I think GrowableArray is definitely not
>> intended for parallel access and therefore such a change may
>> unnecessarily hide other problems where this precondition is violated.
>> So maybe nulling out the '_data' array before freeing it may be a good
>> idea in the debug build to catch such errors!
>>
>> Regards,
>> Volker

From coleen.phillimore at oracle.com  Wed Dec  1 19:47:17 2010
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 01 Dec 2010 22:47:17 -0500
Subject: [Fwd: Re: Request for Review (XS): 6704010: Internal
	Error(src/share/vm/interpreter/interpreterRuntime.cpp:1106)]
In-Reply-To: <4CF70893.8080906@oracle.com>
References: <4CF6B050.6050900@oracle.com> <4CF6D585.3030300@oracle.com>
	<4CF70893.8080906@oracle.com>
Message-ID: <4CF716C5.7030008@oracle.com>

On 12/1/2010 9:46 PM, David Holmes wrote:
> Moving the assertion into a locked region may potentially cause a 
> deadlock if the assertion fails and we go to fatal error handling. 
> We'd need to check that the lock in question is not held in a nested 
> fashion with another lock that might be needed in the fatal error path.
>
> That said there are already potential deadlocks in fatal error 
> handling with some debug/tracing options, so maybe that's a better 
> trade-off than getting the false failure.
Good point.  You could move it so you lock while getting the boolean 
condition and then asserting out of the lock scope.

Coleen  (still happy this bug was diagnosed)
>
> Just a thought.
>
> David Holmes
>
> Coleen Phillimore said the following on 12/02/10 09:08:
>> Volker,
>> This is great.  This was on my bug list.  It looks good to me and 
>> I'll be happy to push it for you.
>> Thanks!
>> Coleen
>>
>> Vladimir Kozlov wrote:
>>> Sending to runtime alias since it is RT bug.
>>>
>>> -------- Original Message --------
>>> Subject: Re: Request for Review (XS): 6704010: Internal Error    
>>> (src/share/vm/interpreter/interpreterRuntime.cpp:1106)
>>> Date: Wed, 1 Dec 2010 19:44:40 +0100
>>> From: Volker Simonis <volker.simonis at gmail.com>
>>> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>>>
>>> http://www.progdoc.de/webrev/6704010/
>>>
>>> This problem occurs very rarely and it is therefore hardly possible to
>>> reliably reproduce it. However after looking at it for a while I think
>>> I found the cause of the problem:
>>>
>>> The SignatureHandlerLibrary class uses two static GrowableArrays,
>>> '_handlers' and '_fingerprints', to store method fingerprints along
>>> with their corresponding signature handlers. But GrowableArrays are
>>> are NOT synchronized in any way if accessed from multiple threads. To
>>> avoid races it is therefore necessary to synchronize different threads
>>> which access the same GrowableArray. This is done for most of the code
>>> in 'SignatureHandlerLibrary::add()' which is protected by 'MutexLocker
>>> mu(SignatureHandlerLibrary_lock)'.
>>>
>>> However the assertion at the end of the method is outside the scope of
>>> this MutexLocker which can lead to an illegal view on the
>>> corresponding GrowableArray data structures. Here'S what may happen in
>>> detail:
>>>
>>>  -thread one enters the section protected by the MutexLocker and adds
>>> another fingerprint/handler to the growable arrays by calling
>>> 'GrowableArray::append()'. This can lead to an implicit call to
>>> 'GrowableArray::grow()' if the arrays size exhausted. In the 'grow()'
>>> method a new data array will be allocated, the contents of the old
>>> array will be copied into the new one and then (1) the storage
>>> occupied by the old array will be freed and (2) the address of the new
>>> storage will be assigned to the internal data pointer. Between (1) and
>>> (2) there's a small (like once every six month or so:) chance that the
>>> thread will be unscheduled and another thread is allocating the memory
>>> which has just been freed.
>>>
>>> - thread two is just in the assertion code and trying to query the
>>> GrowableArrays '_handlers' and '_fingerprints' by calling
>>> 'GrowableArray::find()'. If this happens right in the interval
>>> between the points (1) and (2) described above, the 'find()' method
>>> may return incorrect results which can spuriously trigger the
>>> assertion.
>>>
>>> Fixing this can be easily done by enclosing the assertion into a
>>> region which is protected by the same Mutex like the main body of
>>> 'SignatureHandlerLibrary::add()'.
>>>
>>> As I wrote, I couldn't reproduce this in the HostSpot, so no
>>> regression test. I was however able to reproduce the described
>>> scenario with a standalone GrowableArray class and a small test
>>> program consisting of one writer thread which appends a constant value
>>> to a GrowableArray and ten reader threads which are constantly trying
>>> to find that special value in the array on a dual core x86_64 Linux
>>> box.
>>>
>>> As a last side note, the problem could also be made even more
>>> unlikely, by changing the implementation of   'GrowableArray::grow()'
>>> from:
>>>
>>> template<class E> void GrowableArray<E>::grow(int j) {
>>>     int old_max = _max;
>>>     ...
>>>     if (on_C_heap() && _data != NULL) {
>>>       FreeHeap(_data);
>>>     }
>>>     _data = newData;
>>> }
>>>
>>> to:
>>>
>>> template<class E> void GrowableArray<E>::grow(int j) {
>>>     int old_max = _max;
>>>     ...
>>>     _old_data = _data;
>>>     _data = newData;
>>>     if (on_C_heap() && _old_data != NULL) {
>>>       FreeHeap(_old_data);
>>>     }
>>> }
>>>
>>> On the other hand that's still not 100% safe ('_data' is not volatile,
>>> other memory models, ..) and I think GrowableArray is definitely not
>>> intended for parallel access and therefore such a change may
>>> unnecessarily hide other problems where this precondition is violated.
>>> So maybe nulling out the '_data' array before freeing it may be a good
>>> idea in the debug build to catch such errors!
>>>
>>> Regards,
>>> Volker


From volker.simonis at gmail.com  Thu Dec  2 03:29:52 2010
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 2 Dec 2010 12:29:52 +0100
Subject: [Fwd: Re: Request for Review (XS): 6704010: Internal
	Error(src/share/vm/interpreter/interpreterRuntime.cpp:1106)]
In-Reply-To: <4CF70893.8080906@oracle.com>
References: <4CF6B050.6050900@oracle.com> <4CF6D585.3030300@oracle.com>
	<4CF70893.8080906@oracle.com>
Message-ID: <AANLkTi=51UToG9OMZG+K04g3zAD7G8nBPVyy040Rf9Pb@mail.gmail.com>

Thank you for the review and for pointing out this special problem. I
must confess I haven't thought about it initially.

But I've checked it now and found that 'SignatureHandlerLibrary_lock'
is exclusively used in  'SignatureHandlerLibrary::add()', and I don't
think that during native error handling new signature handlers will be
created.

Nevertheless I've slightly adjusted the change as suggested by Coleen
to get the assertion out of the lock scope:

http://www.progdoc.de/webrev/6704010.v2/

Volker

On Thu, Dec 2, 2010 at 3:46 AM, David Holmes <David.Holmes at oracle.com> wrote:
> Moving the assertion into a locked region may potentially cause a deadlock
> if the assertion fails and we go to fatal error handling. We'd need to check
> that the lock in question is not held in a nested fashion with another lock
> that might be needed in the fatal error path.
>
> That said there are already potential deadlocks in fatal error handling with
> some debug/tracing options, so maybe that's a better trade-off than getting
> the false failure.
>
> Just a thought.
>
> David Holmes
>
> Coleen Phillimore said the following on 12/02/10 09:08:
>>
>> Volker,
>> This is great. ?This was on my bug list. ?It looks good to me and I'll be
>> happy to push it for you.
>> Thanks!
>> Coleen
>>
>> Vladimir Kozlov wrote:
>>>
>>> Sending to runtime alias since it is RT bug.
>>>
>>> -------- Original Message --------
>>> Subject: Re: Request for Review (XS): 6704010: Internal Error
>>> ?(src/share/vm/interpreter/interpreterRuntime.cpp:1106)
>>> Date: Wed, 1 Dec 2010 19:44:40 +0100
>>> From: Volker Simonis <volker.simonis at gmail.com>
>>> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>>>
>>> http://www.progdoc.de/webrev/6704010/
>>>
>>> This problem occurs very rarely and it is therefore hardly possible to
>>> reliably reproduce it. However after looking at it for a while I think
>>> I found the cause of the problem:
>>>
>>> The SignatureHandlerLibrary class uses two static GrowableArrays,
>>> '_handlers' and '_fingerprints', to store method fingerprints along
>>> with their corresponding signature handlers. But GrowableArrays are
>>> are NOT synchronized in any way if accessed from multiple threads. To
>>> avoid races it is therefore necessary to synchronize different threads
>>> which access the same GrowableArray. This is done for most of the code
>>> in 'SignatureHandlerLibrary::add()' which is protected by 'MutexLocker
>>> mu(SignatureHandlerLibrary_lock)'.
>>>
>>> However the assertion at the end of the method is outside the scope of
>>> this MutexLocker which can lead to an illegal view on the
>>> corresponding GrowableArray data structures. Here'S what may happen in
>>> detail:
>>>
>>> ?-thread one enters the section protected by the MutexLocker and adds
>>> another fingerprint/handler to the growable arrays by calling
>>> 'GrowableArray::append()'. This can lead to an implicit call to
>>> 'GrowableArray::grow()' if the arrays size exhausted. In the 'grow()'
>>> method a new data array will be allocated, the contents of the old
>>> array will be copied into the new one and then (1) the storage
>>> occupied by the old array will be freed and (2) the address of the new
>>> storage will be assigned to the internal data pointer. Between (1) and
>>> (2) there's a small (like once every six month or so:) chance that the
>>> thread will be unscheduled and another thread is allocating the memory
>>> which has just been freed.
>>>
>>> - thread two is just in the assertion code and trying to query the
>>> GrowableArrays '_handlers' and '_fingerprints' by calling
>>> 'GrowableArray::find()'. If this happens right in the interval
>>> between the points (1) and (2) described above, the 'find()' method
>>> may return incorrect results which can spuriously trigger the
>>> assertion.
>>>
>>> Fixing this can be easily done by enclosing the assertion into a
>>> region which is protected by the same Mutex like the main body of
>>> 'SignatureHandlerLibrary::add()'.
>>>
>>> As I wrote, I couldn't reproduce this in the HostSpot, so no
>>> regression test. I was however able to reproduce the described
>>> scenario with a standalone GrowableArray class and a small test
>>> program consisting of one writer thread which appends a constant value
>>> to a GrowableArray and ten reader threads which are constantly trying
>>> to find that special value in the array on a dual core x86_64 Linux
>>> box.
>>>
>>> As a last side note, the problem could also be made even more
>>> unlikely, by changing the implementation of ? 'GrowableArray::grow()'
>>> from:
>>>
>>> template<class E> void GrowableArray<E>::grow(int j) {
>>> ? ?int old_max = _max;
>>> ? ?...
>>> ? ?if (on_C_heap() && _data != NULL) {
>>> ? ? ?FreeHeap(_data);
>>> ? ?}
>>> ? ?_data = newData;
>>> }
>>>
>>> to:
>>>
>>> template<class E> void GrowableArray<E>::grow(int j) {
>>> ? ?int old_max = _max;
>>> ? ?...
>>> ? ?_old_data = _data;
>>> ? ?_data = newData;
>>> ? ?if (on_C_heap() && _old_data != NULL) {
>>> ? ? ?FreeHeap(_old_data);
>>> ? ?}
>>> }
>>>
>>> On the other hand that's still not 100% safe ('_data' is not volatile,
>>> other memory models, ..) and I think GrowableArray is definitely not
>>> intended for parallel access and therefore such a change may
>>> unnecessarily hide other problems where this precondition is violated.
>>> So maybe nulling out the '_data' array before freeing it may be a good
>>> idea in the debug build to catch such errors!
>>>
>>> Regards,
>>> Volker
>

From staffan.larsen at oracle.com  Thu Dec  2 06:18:06 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 2 Dec 2010 06:18:06 -0800 (PST)
Subject: Review request (S): 6539281 -Xcheck:jni should validate char*
	argument to ReleaseStringUTFChars
Message-ID: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>

http://cr.openjdk.java.net/~sla/6539281/webrev.00/

 

Validate that ReleaseStringUTFChars/ReleaseStringChars is called with something allocated by GetStringUTChars/GetStringChars when running with -Xcheck:jni. This is accomplished by adding a well-known tag in the memory immediately before the pointer that is returned to the user. This tag is verified in ReleaseStringUTFChars. 

 

Thanks,

/Staffan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101202/10ca9eaa/attachment.html 

From Dmitry.Samersoff at oracle.com  Wed Dec  1 22:44:52 2010
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 02 Dec 2010 09:44:52 +0300
Subject: [Fwd: Re: Request for Review (XS): 6704010: Internal
	Error(src/share/vm/interpreter/interpreterRuntime.cpp:1106)]
In-Reply-To: <4CF716C5.7030008@oracle.com>
References: <4CF6B050.6050900@oracle.com>
	<4CF6D585.3030300@oracle.com>	<4CF70893.8080906@oracle.com>
	<4CF716C5.7030008@oracle.com>
Message-ID: <4CF74064.9060200@oracle.com>

Coleen,

May be:

#ifdef ASSERT

     ...
   {
     MutexLocker mu(SignatureHandlerLibrary_lock);
     a =    _handlers->find(method->signature_handler());
     b = _fingerprints->find(Fingerprinter(method).fingerprint());
   }

    assert(
method->signature_handler() == Interpreter::slow_signature_handler() || 
a == b, "sanity check");

#endif

-Dmitry


On 2010-12-02 06:47, Coleen Phillimore wrote:
> On 12/1/2010 9:46 PM, David Holmes wrote:
>> Moving the assertion into a locked region may potentially cause a
>> deadlock if the assertion fails and we go to fatal error handling.
>> We'd need to check that the lock in question is not held in a nested
>> fashion with another lock that might be needed in the fatal error path.
>>
>> That said there are already potential deadlocks in fatal error
>> handling with some debug/tracing options, so maybe that's a better
>> trade-off than getting the false failure.
> Good point. You could move it so you lock while getting the boolean
> condition and then asserting out of the lock scope.
>
> Coleen (still happy this bug was diagnosed)
>>
>> Just a thought.
>>
>> David Holmes
>>
>> Coleen Phillimore said the following on 12/02/10 09:08:
>>> Volker,
>>> This is great. This was on my bug list. It looks good to me and I'll
>>> be happy to push it for you.
>>> Thanks!
>>> Coleen
>>>
>>> Vladimir Kozlov wrote:
>>>> Sending to runtime alias since it is RT bug.
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: Request for Review (XS): 6704010: Internal Error
>>>> (src/share/vm/interpreter/interpreterRuntime.cpp:1106)
>>>> Date: Wed, 1 Dec 2010 19:44:40 +0100
>>>> From: Volker Simonis <volker.simonis at gmail.com>
>>>> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>>>>
>>>> http://www.progdoc.de/webrev/6704010/
>>>>
>>>> This problem occurs very rarely and it is therefore hardly possible to
>>>> reliably reproduce it. However after looking at it for a while I think
>>>> I found the cause of the problem:
>>>>
>>>> The SignatureHandlerLibrary class uses two static GrowableArrays,
>>>> '_handlers' and '_fingerprints', to store method fingerprints along
>>>> with their corresponding signature handlers. But GrowableArrays are
>>>> are NOT synchronized in any way if accessed from multiple threads. To
>>>> avoid races it is therefore necessary to synchronize different threads
>>>> which access the same GrowableArray. This is done for most of the code
>>>> in 'SignatureHandlerLibrary::add()' which is protected by 'MutexLocker
>>>> mu(SignatureHandlerLibrary_lock)'.
>>>>
>>>> However the assertion at the end of the method is outside the scope of
>>>> this MutexLocker which can lead to an illegal view on the
>>>> corresponding GrowableArray data structures. Here'S what may happen in
>>>> detail:
>>>>
>>>> -thread one enters the section protected by the MutexLocker and adds
>>>> another fingerprint/handler to the growable arrays by calling
>>>> 'GrowableArray::append()'. This can lead to an implicit call to
>>>> 'GrowableArray::grow()' if the arrays size exhausted. In the 'grow()'
>>>> method a new data array will be allocated, the contents of the old
>>>> array will be copied into the new one and then (1) the storage
>>>> occupied by the old array will be freed and (2) the address of the new
>>>> storage will be assigned to the internal data pointer. Between (1) and
>>>> (2) there's a small (like once every six month or so:) chance that the
>>>> thread will be unscheduled and another thread is allocating the memory
>>>> which has just been freed.
>>>>
>>>> - thread two is just in the assertion code and trying to query the
>>>> GrowableArrays '_handlers' and '_fingerprints' by calling
>>>> 'GrowableArray::find()'. If this happens right in the interval
>>>> between the points (1) and (2) described above, the 'find()' method
>>>> may return incorrect results which can spuriously trigger the
>>>> assertion.
>>>>
>>>> Fixing this can be easily done by enclosing the assertion into a
>>>> region which is protected by the same Mutex like the main body of
>>>> 'SignatureHandlerLibrary::add()'.
>>>>
>>>> As I wrote, I couldn't reproduce this in the HostSpot, so no
>>>> regression test. I was however able to reproduce the described
>>>> scenario with a standalone GrowableArray class and a small test
>>>> program consisting of one writer thread which appends a constant value
>>>> to a GrowableArray and ten reader threads which are constantly trying
>>>> to find that special value in the array on a dual core x86_64 Linux
>>>> box.
>>>>
>>>> As a last side note, the problem could also be made even more
>>>> unlikely, by changing the implementation of 'GrowableArray::grow()'
>>>> from:
>>>>
>>>> template<class E> void GrowableArray<E>::grow(int j) {
>>>> int old_max = _max;
>>>> ...
>>>> if (on_C_heap() && _data != NULL) {
>>>> FreeHeap(_data);
>>>> }
>>>> _data = newData;
>>>> }
>>>>
>>>> to:
>>>>
>>>> template<class E> void GrowableArray<E>::grow(int j) {
>>>> int old_max = _max;
>>>> ...
>>>> _old_data = _data;
>>>> _data = newData;
>>>> if (on_C_heap() && _old_data != NULL) {
>>>> FreeHeap(_old_data);
>>>> }
>>>> }
>>>>
>>>> On the other hand that's still not 100% safe ('_data' is not volatile,
>>>> other memory models, ..) and I think GrowableArray is definitely not
>>>> intended for parallel access and therefore such a change may
>>>> unnecessarily hide other problems where this precondition is violated.
>>>> So maybe nulling out the '_data' array before freeing it may be a good
>>>> idea in the debug build to catch such errors!
>>>>
>>>> Regards,
>>>> Volker
>


-- 
Dmitry Samersoff
J2SE Sustaining team, SPB04
* Give Rabbit time and he'll always get the answer ...

From keith.mcguigan at oracle.com  Thu Dec  2 08:34:18 2010
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Thu, 2 Dec 2010 11:34:18 -0500
Subject: Review request (S): 6539281 -Xcheck:jni should validate char*
	argument to ReleaseStringUTFChars
In-Reply-To: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
References: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
Message-ID: <FE7226AA-FC47-4E90-AE82-C657E3123E61@oracle.com>


On Dec 2, 2010, at 9:18 AM, Staffan Larsen wrote:

> http://cr.openjdk.java.net/~sla/6539281/webrev.00/
>
> Validate that ReleaseStringUTFChars/ReleaseStringChars is called  
> with something allocated by GetStringUTChars/GetStringChars when  
> running with -Xcheck:jni. This is accomplished by adding a well- 
> known tag in the memory immediately before the pointer that is  
> returned to the user. This tag is verified in ReleaseStringUTFChars.
>
> Thanks,
> /Staffan

Looks good to me -- with the very minor nit that the star should be  
with the type (jint) instead of the variable name (tagLocation) on  
line 1324.

--
- Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101202/68a7287d/attachment.html 

From Dmitry.Samersoff at oracle.com  Thu Dec  2 09:12:34 2010
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 02 Dec 2010 20:12:34 +0300
Subject: Review request (S): 6539281 -Xcheck:jni should validate char*
	argument to ReleaseStringUTFChars
In-Reply-To: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
References: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
Message-ID: <4CF7D382.6050309@oracle.com>

Staffan,

1. Logically string argument of GetStringChars and ReleaseStringChars 
have to be the same.
   So:
     checked_jni_ReleaseStringChars:
        chars_to_check = GetStringChars(env,str,isCopy);
        memcmp(chars,chars_to_check, len > 10 ? 10 : len);

could be a better approach.

BUT:

2.
As far as I know GetStringChars do alloc/memcpy inside it
Could we avoid extra copying?

3.
Code below:
jint *tagLocation = ((jint*) chars) - 1;

Could lead to cryptic crash e.g. if we pass 0 as a char (common case) to 
this code we will have a crash on read from 0xFFFFFFFF rather than much 
more clean crash on zero-access. So either gurantee chars != 0 have to 
be there or tag should be placed at the end of chars, after terminating 
zero.

-Dmitry



On 2010-12-02 17:18, Staffan Larsen wrote:
> http://cr.openjdk.java.net/~sla/6539281/webrev.00/
>
> Validate that ReleaseStringUTFChars/ReleaseStringChars is called with
> something allocated by GetStringUTChars/GetStringChars when running with
> -Xcheck:jni. This is accomplished by adding a well-known tag in the
> memory immediately before the pointer that is returned to the user. This
> tag is verified in ReleaseStringUTFChars.
>
> Thanks,
>
> /Staffan
>


-- 
Dmitry Samersoff
J2SE Sustaining team, SPB04
* Give Rabbit time and he'll always get the answer ...

From tom.rodriguez at oracle.com  Thu Dec  2 11:03:00 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 2 Dec 2010 11:03:00 -0800
Subject: Review request (S): 6539281 -Xcheck:jni should validate char*
	argument to ReleaseStringUTFChars
In-Reply-To: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
References: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
Message-ID: <5137D0FC-0F6D-4DE6-B2B0-161F058D152A@oracle.com>


On Dec 2, 2010, at 6:18 AM, Staffan Larsen wrote:

> http://cr.openjdk.java.net/~sla/6539281/webrev.00/
>  
> Validate that ReleaseStringUTFChars/ReleaseStringChars is called with something allocated by GetStringUTChars/GetStringChars when running with -Xcheck:jni. This is accomplished by adding a well-known tag in the memory immediately before the pointer that is returned to the user. This tag is verified in ReleaseStringUTFChars.

Won't this cause the dtrace arguments not to match up anymore?  The return probe for GetStringChars will report the original allocation but the ReleaseStringChars will be passed the new allocation so they won't agree.  It's a minor issue but it does seem odd.

You might consider asserting that isCopy == true.

tom

>  
> Thanks,
> /Staffan


From staffan.larsen at oracle.com  Thu Dec  2 11:11:19 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 2 Dec 2010 20:11:19 +0100
Subject: Review request (S): 6539281 -Xcheck:jni should validate char*
	argument to ReleaseStringUTFChars
In-Reply-To: <4CF7D382.6050309@oracle.com>
References: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
	<4CF7D382.6050309@oracle.com>
Message-ID: <3441BF30-5C1A-4F0C-BB45-FF7006064106@oracle.com>

Dmitry,

1) Yes, I agree. But for ReleaseStringUTFChars a similar check would require a UTF conversion which I'd like to avoid. And I prefer to have similar code in both the UTF and non-UTF case. It has been suggested that the similiar code should be abstracted into some helper method, but I can't figure a way that doesn't make the code more complex and harder to read.

2) Any ideas?

3) Yes, "chars" should definitely be NULL-checked.

Thanks,
/Staffan

On 2 dec 2010, at 18.12, Dmitry Samersoff wrote:

> Staffan,
> 
> 1. Logically string argument of GetStringChars and ReleaseStringChars have to be the same.
>  So:
>    checked_jni_ReleaseStringChars:
>       chars_to_check = GetStringChars(env,str,isCopy);
>       memcmp(chars,chars_to_check, len > 10 ? 10 : len);
> 
> could be a better approach.
> 
> BUT:
> 
> 2.
> As far as I know GetStringChars do alloc/memcpy inside it
> Could we avoid extra copying?
> 
> 3.
> Code below:
> jint *tagLocation = ((jint*) chars) - 1;
> 
> Could lead to cryptic crash e.g. if we pass 0 as a char (common case) to this code we will have a crash on read from 0xFFFFFFFF rather than much more clean crash on zero-access. So either gurantee chars != 0 have to be there or tag should be placed at the end of chars, after terminating zero.
> 
> -Dmitry
> 
> 
> 
> On 2010-12-02 17:18, Staffan Larsen wrote:
>> http://cr.openjdk.java.net/~sla/6539281/webrev.00/
>> 
>> Validate that ReleaseStringUTFChars/ReleaseStringChars is called with
>> something allocated by GetStringUTChars/GetStringChars when running with
>> -Xcheck:jni. This is accomplished by adding a well-known tag in the
>> memory immediately before the pointer that is returned to the user. This
>> tag is verified in ReleaseStringUTFChars.
>> 
>> Thanks,
>> 
>> /Staffan
>> 
> 
> 
> -- 
> Dmitry Samersoff
> J2SE Sustaining team, SPB04
> * Give Rabbit time and he'll always get the answer ...


From staffan.larsen at oracle.com  Thu Dec  2 11:14:21 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 2 Dec 2010 20:14:21 +0100
Subject: Review request (S): 6539281 -Xcheck:jni should validate char*
	argument to ReleaseStringUTFChars
In-Reply-To: <5137D0FC-0F6D-4DE6-B2B0-161F058D152A@oracle.com>
References: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
	<5137D0FC-0F6D-4DE6-B2B0-161F058D152A@oracle.com>
Message-ID: <8D212A1E-7702-4DCC-931D-0AEA7A795363@oracle.com>

Yes, you are right. I can't figure out a way to avoid this, unless I copy all of the code from the normal methods into jniCheck.cpp and never call the unchecked versions.

Will do the isCopy == true check.

/Staffan

On 2 dec 2010, at 20.03, Tom Rodriguez wrote:

> 
> On Dec 2, 2010, at 6:18 AM, Staffan Larsen wrote:
> 
>> http://cr.openjdk.java.net/~sla/6539281/webrev.00/
>> 
>> Validate that ReleaseStringUTFChars/ReleaseStringChars is called with something allocated by GetStringUTChars/GetStringChars when running with -Xcheck:jni. This is accomplished by adding a well-known tag in the memory immediately before the pointer that is returned to the user. This tag is verified in ReleaseStringUTFChars.
> 
> Won't this cause the dtrace arguments not to match up anymore?  The return probe for GetStringChars will report the original allocation but the ReleaseStringChars will be passed the new allocation so they won't agree.  It's a minor issue but it does seem odd.
> 
> You might consider asserting that isCopy == true.
> 
> tom
> 
>> 
>> Thanks,
>> /Staffan
> 


From tom.rodriguez at oracle.com  Thu Dec  2 13:13:25 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 2 Dec 2010 13:13:25 -0800
Subject: Review request (S): 6539281 -Xcheck:jni should validate char*
	argument to ReleaseStringUTFChars
In-Reply-To: <8D212A1E-7702-4DCC-931D-0AEA7A795363@oracle.com>
References: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
	<5137D0FC-0F6D-4DE6-B2B0-161F058D152A@oracle.com>
	<8D212A1E-7702-4DCC-931D-0AEA7A795363@oracle.com>
Message-ID: <F40CE349-0F57-4AC3-B2A7-5EBD67A0671A@oracle.com>


On Dec 2, 2010, at 11:14 AM, Staffan Larsen wrote:

> Yes, you are right. I can't figure out a way to avoid this, unless I copy all of the code from the normal methods into jniCheck.cpp and never call the unchecked versions.

It's probably not a big deal since it only affects -Xcheck:jni.

tom

> 
> Will do the isCopy == true check.
> 
> /Staffan
> 
> On 2 dec 2010, at 20.03, Tom Rodriguez wrote:
> 
>> 
>> On Dec 2, 2010, at 6:18 AM, Staffan Larsen wrote:
>> 
>>> http://cr.openjdk.java.net/~sla/6539281/webrev.00/
>>> 
>>> Validate that ReleaseStringUTFChars/ReleaseStringChars is called with something allocated by GetStringUTChars/GetStringChars when running with -Xcheck:jni. This is accomplished by adding a well-known tag in the memory immediately before the pointer that is returned to the user. This tag is verified in ReleaseStringUTFChars.
>> 
>> Won't this cause the dtrace arguments not to match up anymore?  The return probe for GetStringChars will report the original allocation but the ReleaseStringChars will be passed the new allocation so they won't agree.  It's a minor issue but it does seem odd.
>> 
>> You might consider asserting that isCopy == true.
>> 
>> tom
>> 
>>> 
>>> Thanks,
>>> /Staffan
>> 
> 


From bob.vandette at oracle.com  Thu Dec  2 15:48:11 2010
From: bob.vandette at oracle.com (bob.vandette at oracle.com)
Date: Thu, 02 Dec 2010 23:48:11 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7004217: Remove IA64 workaround
	re-introduced with CR6953477
Message-ID: <20101202234813.AADDA4702D@hg.openjdk.java.net>

Changeset: 6a2d73358ff7
Author:    bobv
Date:      2010-12-02 14:00 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6a2d73358ff7

7004217: Remove IA64 workaround re-introduced with CR6953477
Summary: gcc bug worksaround for IA64 no longer needed
Reviewed-by: andrew

! src/share/vm/interpreter/bytecodeInterpreter.cpp


From john.coomes at oracle.com  Thu Dec  2 20:55:49 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Dec 2010 04:55:49 +0000
Subject: hg: jdk7/hotspot-rt: Added tag jdk7-b120 for changeset 366ff0b6d215
Message-ID: <20101203045549.D29D447055@hg.openjdk.java.net>

Changeset: 6f79b68d1851
Author:    cl
Date:      2010-12-02 19:03 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/6f79b68d1851

Added tag jdk7-b120 for changeset 366ff0b6d215

! .hgtags


From john.coomes at oracle.com  Thu Dec  2 20:55:55 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Dec 2010 04:55:55 +0000
Subject: hg: jdk7/hotspot-rt/corba: Added tag jdk7-b120 for changeset
	cff5a173ec1e
Message-ID: <20101203045558.8334947056@hg.openjdk.java.net>

Changeset: 4ab3c663d147
Author:    cl
Date:      2010-12-02 19:03 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/4ab3c663d147

Added tag jdk7-b120 for changeset cff5a173ec1e

! .hgtags


From john.coomes at oracle.com  Thu Dec  2 20:56:04 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Dec 2010 04:56:04 +0000
Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b120 for changeset
	4821de0908de
Message-ID: <20101203045604.9E18047057@hg.openjdk.java.net>

Changeset: c3a09068ab6c
Author:    cl
Date:      2010-12-02 19:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/c3a09068ab6c

Added tag jdk7-b120 for changeset 4821de0908de

! .hgtags


From john.coomes at oracle.com  Thu Dec  2 20:56:10 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Dec 2010 04:56:10 +0000
Subject: hg: jdk7/hotspot-rt/jaxws: Added tag jdk7-b120 for changeset
	a4f2e1ca6716
Message-ID: <20101203045611.07C0D47058@hg.openjdk.java.net>

Changeset: aff278ea6189
Author:    cl
Date:      2010-12-02 19:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/aff278ea6189

Added tag jdk7-b120 for changeset a4f2e1ca6716

! .hgtags


From john.coomes at oracle.com  Thu Dec  2 20:56:20 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Dec 2010 04:56:20 +0000
Subject: hg: jdk7/hotspot-rt/jdk: 2 new changesets
Message-ID: <20101203045712.DB5D047059@hg.openjdk.java.net>

Changeset: 37d74e29687c
Author:    ksrini
Date:      2010-11-29 13:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/37d74e29687c

7003227: (pack200) intermittent failures compiling pack200
Reviewed-by: jjg

! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java
! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java
! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java
! src/share/classes/com/sun/java/util/jar/pack/Code.java
! src/share/classes/com/sun/java/util/jar/pack/Coding.java
! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java
! src/share/classes/com/sun/java/util/jar/pack/CodingMethod.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Constants.java
! src/share/classes/com/sun/java/util/jar/pack/Driver.java
! src/share/classes/com/sun/java/util/jar/pack/Fixups.java
! src/share/classes/com/sun/java/util/jar/pack/Histogram.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/Package.java
! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java
! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java
! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/Utils.java

Changeset: d4eda9a6328e
Author:    cl
Date:      2010-12-02 19:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d4eda9a6328e

Added tag jdk7-b120 for changeset 37d74e29687c

! .hgtags


From john.coomes at oracle.com  Thu Dec  2 20:57:43 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 03 Dec 2010 04:57:43 +0000
Subject: hg: jdk7/hotspot-rt/langtools: 103 new changesets
Message-ID: <20101203050053.143094705A@hg.openjdk.java.net>

Changeset: 47e7ff871196
Author:    ohair
Date:      2010-09-07 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/47e7ff871196

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: f4d91b4f7153
Author:    cl
Date:      2010-09-03 12:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f4d91b4f7153

Added tag jdk7-b108 for changeset a408ebb8b3d4

! .hgtags

Changeset: 4826378eaade
Author:    cl
Date:      2010-09-09 13:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4826378eaade

Merge


Changeset: 1c13c5ea73b5
Author:    cl
Date:      2010-09-09 15:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/1c13c5ea73b5

Added tag jdk7-b109 for changeset 4826378eaade

! .hgtags

Changeset: b599cc9a9c22
Author:    ohair
Date:      2010-09-09 16:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/b599cc9a9c22

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! test/tools/javac/generics/inference/6938454/T6938454a.java
! test/tools/javac/generics/inference/6938454/T6938454b.java

Changeset: 32da0f38d2fe
Author:    cl
Date:      2010-09-15 13:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/32da0f38d2fe

Merge


Changeset: 8bec624274ef
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/8bec624274ef

Added tag jdk7-b110 for changeset 32da0f38d2fe

! .hgtags

Changeset: 7ad86852c38a
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/7ad86852c38a

Added tag jdk7-b111 for changeset 8bec624274ef

! .hgtags

Changeset: e9d09e97d669
Author:    jjg
Date:      2010-08-24 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/e9d09e97d669

6935638: -implicit:none prevents compilation with annotation processing
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/processing/options/TestImplicitNone.java

Changeset: f3323b1c65ee
Author:    jjg
Date:      2010-08-24 15:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f3323b1c65ee

6929404: Filer.getResource(SOURCE_PATH, ...) does not work when -sourcepath contains >1 entry
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java
+ test/tools/javac/processing/filer/TestGetResource2.java

Changeset: 6ef801fa38b7
Author:    jjg
Date:      2010-08-25 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/6ef801fa38b7

6979564: ":" for path separator in dist/bin/javac does not work on Windows
Reviewed-by: jjh

! make/build.xml
! src/share/bin/launcher.sh-template

Changeset: 70ebdef189c9
Author:    jjg
Date:      2010-08-25 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/70ebdef189c9

6960424: new option -Xpkginfo for better control of when package-info.class is generated
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/main/OptionName.java
! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java
! src/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/TestPkgInfo.java

Changeset: ecff24121064
Author:    naoto
Date:      2010-08-25 15:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/ecff24121064

6875847: Java Locale Enhancement
Summary: Fix for javac to allow "sun.util.locale" package accessible.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/resources/legacy.properties

Changeset: cfd047f3cf60
Author:    jjg
Date:      2010-08-26 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/cfd047f3cf60

6604599: ToolProvider should be less compiler-specific
Reviewed-by: darcy

! src/share/classes/javax/tools/ToolProvider.java
+ test/tools/javac/api/ToolProvider/HelloWorldTest.java
+ test/tools/javac/api/ToolProvider/ToolProviderTest1.java
+ test/tools/javac/api/ToolProvider/ToolProviderTest2.java

Changeset: ae3acbf63943
Author:    jjg
Date:      2010-08-26 16:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/ae3acbf63943

6980017: javap -XDdetail:source behaves badly if source not available.
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javap/CodeWriter.java
! src/share/classes/com/sun/tools/javap/SourceWriter.java
+ test/tools/javap/T6980017.java

Changeset: 3a9f319be48a
Author:    jjg
Date:      2010-08-27 17:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/3a9f319be48a

6980724: test/tools/javac/InterfaceAssert.java sometimes fails
Reviewed-by: darcy

! test/tools/javac/InterfaceAssert.java

Changeset: b4e7a57af8df
Author:    jjg
Date:      2010-08-27 17:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/b4e7a57af8df

6570730: com.sun.source.tree.ModifiersTree.getFlags() should return class type
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
- test/tools/javac/T6341023.java
+ test/tools/javac/tree/ClassTreeTest.java
+ test/tools/javac/tree/TreeKindTest.java

Changeset: eb7c263aab73
Author:    jjg
Date:      2010-08-27 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/eb7c263aab73

6980707: Reduce use of IOException in JavaCompiler
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/FatalError.java
! test/tools/javac/diags/examples.not-yet.txt

Changeset: 4124840b35fe
Author:    jjg
Date:      2010-08-30 18:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4124840b35fe

6403465: javac should defer diagnostics until it can be determined they are persistent
Reviewed-by: mcimadamore, darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! test/tools/javac/processing/6430209/b6341534.java
+ test/tools/javac/processing/errors/TestSuppression.java

Changeset: d3ead6731a91
Author:    jrose
Date:      2010-09-01 03:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d3ead6731a91

6979683: inconsistent interaction of reference cast with box/unbox conversions leaves out a useful case
Summary: Allow casts which narrow and then unbox.
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/6979683/TestCast6979683_BAD34.java
+ test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD35.java
+ test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD36.java
+ test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD37.java
+ test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD38.java
+ test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD39.java
+ test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog
+ test/tools/javac/6979683/TestCast6979683_GOOD.java

Changeset: f37253c9e082
Author:    sundar
Date:      2010-09-02 23:10 +0530
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f37253c9e082

6458749: TypeParameterElement.getEnclosedElements throws NPE within javac.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/T6458749.java

Changeset: 3ff3f20471b4
Author:    jjg
Date:      2010-09-02 18:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/3ff3f20471b4

6921495: spurious semicolons in class def cause empty NOPOS blocks
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/parser/ExtraSemiTest.java

Changeset: 25dd23fa2511
Author:    sundar
Date:      2010-09-03 11:25 +0530
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/25dd23fa2511

6458823: Messager messages on TypeParamterElements to not include position information.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/T6458823/MyProcessor.java
+ test/tools/javac/T6458823/T6458823.java
+ test/tools/javac/T6458823/TestClass.java

Changeset: d54300fb3554
Author:    sundar
Date:      2010-09-03 12:36 +0530
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d54300fb3554

6956462: AssertionError exception thrown in the Compiler Tree API in JDK 7.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/T6956462/T6956462.java
+ test/tools/javac/T6956462/TestClass.java

Changeset: 3fba23db9619
Author:    lana
Date:      2010-09-02 22:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/3fba23db9619

Merge


Changeset: 68e765b1e9ed
Author:    lana
Date:      2010-09-03 12:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/68e765b1e9ed

Merge


Changeset: ea54372637a5
Author:    jjg
Date:      2010-09-06 12:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/ea54372637a5

6930507: Symbols for anonymous and local classes made too late for use by java tree API
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/api/TestGetElement.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/processing/model/element/TestAnonSourceNames.java

Changeset: 7ae4016c5938
Author:    mcimadamore
Date:      2010-09-07 17:31 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/7ae4016c5938

6337171: javac should create bridge methods when type variable bounds restricted
Summary: javac should add synthetic overrides for inherited abstract methods in order to preserve binary compatibility
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! 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/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ src/share/classes/com/sun/tools/javac/util/Filter.java
+ test/tools/javac/generics/OverrideBridge.java

Changeset: 584365f256a7
Author:    mcimadamore
Date:      2010-09-07 17:32 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/584365f256a7

6979327: method handle invocation should use casts instead of type parameters to specify return type
Summary: infer return type for polymorphic signature calls according to updated JSR 292 draft
Reviewed-by: jjg
Contributed-by: john.r.rose at oracle.com

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/Names.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java
+ test/tools/javac/diags/examples/UnsupportedExoticID.java
! test/tools/javac/meth/InvokeDyn.java
+ test/tools/javac/meth/InvokeDynTrans.java
+ test/tools/javac/meth/InvokeDynTrans.out
! test/tools/javac/meth/InvokeMH.java
+ test/tools/javac/meth/InvokeMHTrans.java
+ test/tools/javac/meth/InvokeMHTrans.out
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
! test/tools/javac/quid/QuotedIdent.java
! test/tools/javac/quid/QuotedIdent2.java

Changeset: 12d8f7e417fd
Author:    mcimadamore
Date:      2010-09-07 17:32 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/12d8f7e417fd

6981185: com.sun.tools.model.JavacTypes.contains() calls Type.contains instead of Types.containsType
Summary: wrong implementation is causing trivial containment tests to fail unexpectedly (when such tests are executed using compiler API)
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
+ test/tools/javac/api/TestContainTypes.java

Changeset: bfdfc13fe641
Author:    mcimadamore
Date:      2010-09-07 17:33 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/bfdfc13fe641

6970584: Flow.java should be more error-friendly
Summary: Added a post-attribution visitor that fixup uninitialized types/symbol in AST after erroneous attribution
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symtab.java
! 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/main/JavaCompiler.java
+ test/tools/javac/failover/CheckAttributedTree.java
+ test/tools/javac/failover/FailOver01.java
+ test/tools/javac/failover/FailOver01.out
+ test/tools/javac/failover/FailOver02.java
+ test/tools/javac/failover/FailOver02.out
+ test/tools/javac/failover/FailOver03.java
+ test/tools/javac/failover/FailOver03.out
+ test/tools/javac/failover/FailOver04.java
+ test/tools/javac/failover/FailOver04.out
+ test/tools/javac/failover/FailOver05.java
+ test/tools/javac/failover/FailOver05.out
+ test/tools/javac/failover/FailOver06.java
+ test/tools/javac/failover/FailOver06.out
+ test/tools/javac/failover/FailOver07.java
+ test/tools/javac/failover/FailOver07.out
+ test/tools/javac/failover/FailOver08.java
+ test/tools/javac/failover/FailOver08.out
+ test/tools/javac/failover/FailOver09.java
+ test/tools/javac/failover/FailOver09.out
+ test/tools/javac/failover/FailOver10.java
+ test/tools/javac/failover/FailOver10.out
+ test/tools/javac/failover/FailOver11.java
+ test/tools/javac/failover/FailOver11.out
+ test/tools/javac/failover/FailOver12.java
+ test/tools/javac/failover/FailOver12.out
+ test/tools/javac/failover/FailOver13.java
+ test/tools/javac/failover/FailOver13.out
+ test/tools/javac/failover/FailOver14.java
+ test/tools/javac/failover/FailOver14.out

Changeset: c388fa8c6a43
Author:    ohair
Date:      2010-09-07 15:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/c388fa8c6a43

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh

Changeset: 014cf6234586
Author:    sundar
Date:      2010-09-09 09:42 +0530
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/014cf6234586

6900149: IllegalStateException when compiling same files and DiagnosticListener is set.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/T6900149.java

Changeset: fc73f83cd563
Author:    jjg
Date:      2010-09-09 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/fc73f83cd563

6983239: TreeScanner does not scan default value for method
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/TreeScanner.java
! test/tools/javac/api/T6392782.java
+ test/tools/javac/tree/AbstractTreeScannerTest.java
+ test/tools/javac/tree/JavacTreeScannerTest.java
+ test/tools/javac/tree/SourceTreeScannerTest.java
- test/tools/javac/tree/TreeScannerTest.java

Changeset: 80505c2026e7
Author:    jjg
Date:      2010-09-13 11:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/80505c2026e7

6965264: langtools build should use ${ant.core.lib} instead of ${ant.home}/lib/ant.jar
Reviewed-by: mcimadamore
Contributed-by: jesse.glick at oracle.com

! make/build.xml

Changeset: e92ae290fb47
Author:    jjg
Date:      2010-09-13 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/e92ae290fb47

6978974: [langtools] <findbugs> task should use ${target.java.home}
Reviewed-by: mcimadamore

! make/build.xml

Changeset: 6e2ccba61117
Author:    jjg
Date:      2010-09-16 09:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/6e2ccba61117

6985181: Annotations lost from classfile
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
+ test/tools/javac/T6985181.java

Changeset: bbc9765d9ec6
Author:    jjg
Date:      2010-09-16 09:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/bbc9765d9ec6

6985115: tests create too much output
Reviewed-by: mcimadamore

! test/tools/javac/T6855236.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/tree/AbstractTreeScannerTest.java
! test/tools/javac/tree/JavacTreeScannerTest.java
! test/tools/javac/tree/SourceTreeScannerTest.java
! test/tools/javap/T6868539.java
! test/tools/javap/T6980017.java

Changeset: c5df455918c4
Author:    lana
Date:      2010-09-16 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/c5df455918c4

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/tree/TreeScannerTest.java

Changeset: fd2579b80b83
Author:    lana
Date:      2010-09-24 16:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/fd2579b80b83

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/tree/TreeScannerTest.java

Changeset: 6dbd2d869b05
Author:    cl
Date:      2010-10-01 15:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/6dbd2d869b05

Added tag jdk7-b112 for changeset fd2579b80b83

! .hgtags

Changeset: cd3235a96b6c
Author:    cl
Date:      2010-10-07 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/cd3235a96b6c

Added tag jdk7-b113 for changeset 6dbd2d869b05

! .hgtags

Changeset: 50f9ac2f4730
Author:    mcimadamore
Date:      2010-09-18 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/50f9ac2f4730

6980862: too aggressive compiler optimization causes stale results of Types.implementation()
Summary: use a scope counter in order to determine when/if the implementation cache entries are stale
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java

Changeset: 77cc34d5e548
Author:    mcimadamore
Date:      2010-09-18 09:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/77cc34d5e548

5088624: cannot find symbol message should be more intelligent
Summary: Resolve.java should keep track of all candidates found during a method resolution sweep to generate more meaningful diagnostics
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java
! test/tools/javac/6758789/T6758789a.out
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/6857948/T6857948.out
! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6722234/T6722234c.out
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/Diagnostics/6862608/T6862608b.out
! test/tools/javac/T6326754.out
! test/tools/javac/diags/Example.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java
+ test/tools/javac/diags/examples/InapplicableSymbols.java
! test/tools/javac/diags/examples/IncompatibleTypes1.java
+ test/tools/javac/diags/examples/InferArgsLengthMismatch.java
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/diags/examples/NoArgs.java
+ test/tools/javac/diags/examples/VarargsArgumentMismatch.java
! test/tools/javac/diags/examples/WhereCaptured.java
! test/tools/javac/diags/examples/WhereCaptured1.java
! test/tools/javac/diags/examples/WhereTypeVar.java
! test/tools/javac/generics/diamond/neg/Neg06.out
! test/tools/javac/generics/inference/6315770/T6315770.out
! test/tools/javac/generics/inference/6611449/T6611449.out
! test/tools/javac/generics/inference/6638712/T6638712a.out
! test/tools/javac/generics/inference/6638712/T6638712b.out
! test/tools/javac/generics/inference/6638712/T6638712c.out
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6638712/T6638712e.out

Changeset: 0c1ef2af7a8e
Author:    mcimadamore
Date:      2010-09-18 14:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/0c1ef2af7a8e

6863465: javac doesn't detect circular subclass dependencies via qualified names
Summary: class inheritance circularity check should look at trees, not just symbols
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/6863465/T6863465a.java
+ test/tools/javac/6863465/T6863465a.out
+ test/tools/javac/6863465/T6863465b.java
+ test/tools/javac/6863465/T6863465b.out
+ test/tools/javac/6863465/T6863465c.java
+ test/tools/javac/6863465/T6863465c.out
+ test/tools/javac/6863465/T6863465d.java
+ test/tools/javac/6863465/T6863465d.out
+ test/tools/javac/6863465/TestCircularClassfile.java
! test/tools/javac/CyclicInheritance.out
! test/tools/javac/NameCollision.out

Changeset: da7ca56d092c
Author:    sundar
Date:      2010-09-22 20:53 +0530
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/da7ca56d092c

6587674: NoClassdefFound when anonymously extending a class.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T6587674.java

Changeset: 3eea38ce151c
Author:    jjg
Date:      2010-09-22 12:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/3eea38ce151c

6986772: langtools netbeans build should use ${ant.core.lib} instead of ${ant.home}/lib/ant.jar
Reviewed-by: ohair

! make/netbeans/langtools/build.xml

Changeset: 827d87221959
Author:    lana
Date:      2010-09-25 12:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/827d87221959

Merge


Changeset: f6fe12839a8a
Author:    jjg
Date:      2010-09-27 14:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f6fe12839a8a

6890226: javah -version is broken
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/com/sun/tools/javah/resources/l10n.properties
+ src/share/classes/com/sun/tools/javah/resources/version.properties-template
+ test/tools/javah/VersionTest.java

Changeset: 3c9b64e55c5d
Author:    jjg
Date:      2010-09-27 14:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/3c9b64e55c5d

6877202: Elements.getDocComment() is not getting JavaDocComments
6861094: javac -Xprint <file> does not print comments
6985205: access to tree positions and doc comments may be lost across annotation processing rounds
Reviewed-by: darcy

! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
+ src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java
! src/share/classes/com/sun/tools/javadoc/JavadocTool.java
! test/tools/javac/6302184/T6302184.out
! test/tools/javac/6304921/TestLog.java
! test/tools/javac/api/TestJavacTaskScanner.java
- test/tools/javac/processing/Xprint.java
+ test/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java
+ test/tools/javac/processing/model/util/elements/doccomments/a/First.java
+ test/tools/javac/processing/model/util/elements/doccomments/z/Last.java
+ test/tools/javac/processing/options/Xprint.java
+ test/tools/javac/processing/options/XprintDocComments.java
+ test/tools/javac/processing/options/XprintDocComments.out
+ test/tools/javac/tree/TreePosRoundsTest.java

Changeset: d4df3b6ee729
Author:    jjg
Date:      2010-09-27 17:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d4df3b6ee729

6986246: Trees object is round-specific
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! test/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java
! test/tools/javac/tree/TreePosRoundsTest.java

Changeset: 28b021bb889f
Author:    sundar
Date:      2010-09-28 22:46 +0530
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/28b021bb889f

6967842: Element not returned from tree API for ARM resource variables.
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/processing/model/element/TestResourceElement.java
! test/tools/javac/processing/model/element/TestResourceVariable.java

Changeset: f94af0667151
Author:    jjg
Date:      2010-09-29 14:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f94af0667151

6502392: Invalid relative names for Filer.createResource and Filer.getResource
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
+ test/tools/javac/processing/filer/TestInvalidRelativeNames.java

Changeset: d2aaaec153e8
Author:    darcy
Date:      2010-09-29 23:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d2aaaec153e8

6983738: Use a JavacTestingAbstractProcessor
Reviewed-by: jjg

+ test/tools/javac/lib/JavacTestingAbstractProcessor.java
! test/tools/javac/processing/6348499/A.java
! test/tools/javac/processing/6348499/T6348499.java
! test/tools/javac/processing/6359313/T6359313.java
! test/tools/javac/processing/6365040/ProcBar.java
! test/tools/javac/processing/6365040/ProcFoo.java
! test/tools/javac/processing/6365040/T6365040.java
! test/tools/javac/processing/6413690/T6413690.java
! test/tools/javac/processing/6414633/A.java
! test/tools/javac/processing/6414633/T6414633.java
! test/tools/javac/processing/6430209/T6430209.java
! test/tools/javac/processing/6430209/b6341534.java
! test/tools/javac/processing/6499119/ClassProcessor.java
! test/tools/javac/processing/6511613/DummyProcessor.java
! test/tools/javac/processing/6511613/clss41701.java
! test/tools/javac/processing/6512707/T6512707.java
! test/tools/javac/processing/6634138/T6634138.java
! test/tools/javac/processing/T6439826.java
! test/tools/javac/processing/T6920317.java
! test/tools/javac/processing/environment/TestSourceVersion.java
! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java
! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java
! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java
! test/tools/javac/processing/errors/TestReturnCode.java
! test/tools/javac/processing/filer/TestFilerConstraints.java
! test/tools/javac/processing/filer/TestGetResource.java
! test/tools/javac/processing/filer/TestGetResource2.java
! test/tools/javac/processing/filer/TestInvalidRelativeNames.java
! test/tools/javac/processing/filer/TestLastRound.java
! test/tools/javac/processing/filer/TestPackageInfo.java
! test/tools/javac/processing/messager/6362067/T6362067.java
! test/tools/javac/processing/messager/MessagerBasics.java
! test/tools/javac/processing/model/6194785/T6194785.java
! test/tools/javac/processing/model/6341534/T6341534.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/processing/model/element/TestAnonSourceNames.java
! test/tools/javac/processing/model/element/TestElement.java
! test/tools/javac/processing/model/element/TestNames.java
! test/tools/javac/processing/model/element/TestPackageElement.java
! test/tools/javac/processing/model/element/TestResourceElement.java
! test/tools/javac/processing/model/element/TestResourceVariable.java
! test/tools/javac/processing/model/element/TypeParamBounds.java
! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java
! test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java
! test/tools/javac/processing/model/type/NoTypes.java
! test/tools/javac/processing/model/util/BinaryName.java
! test/tools/javac/processing/model/util/GetTypeElemBadArg.java
! test/tools/javac/processing/model/util/NoSupers.java
! test/tools/javac/processing/model/util/OverridesSpecEx.java
! test/tools/javac/processing/model/util/TypesBadArg.java
! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java
! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java
! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java
! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java
! test/tools/javac/processing/model/util/filter/TestIterables.java
! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java
! test/tools/javac/processing/werror/WError1.java
! test/tools/javac/processing/werror/WErrorGen.java
! test/tools/javac/processing/werror/WErrorLast.java

Changeset: 7b413ac1a720
Author:    jjg
Date:      2010-09-30 10:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/7b413ac1a720

6988436: Cleanup javac option handling
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javac/util/Names.java
! src/share/classes/com/sun/tools/javac/util/Options.java

Changeset: 232919708730
Author:    alanb
Date:      2010-10-03 19:40 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/232919708730

6907737: (file) FileVisitor and Files.walkFileTree issues
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java

Changeset: 2c321dcb1edc
Author:    lana
Date:      2010-10-04 14:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2c321dcb1edc

Merge

- test/tools/javac/processing/Xprint.java

Changeset: e4e7408cdc5b
Author:    lana
Date:      2010-10-12 12:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/e4e7408cdc5b

Merge

- test/tools/javac/processing/Xprint.java

Changeset: 01e8ac5fbefd
Author:    cl
Date:      2010-10-14 19:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/01e8ac5fbefd

Added tag jdk7-b114 for changeset e4e7408cdc5b

! .hgtags

Changeset: b7f12ec175bb
Author:    cl
Date:      2010-10-21 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/b7f12ec175bb

Added tag jdk7-b115 for changeset 01e8ac5fbefd

! .hgtags

Changeset: 971c8132f5b2
Author:    jjg
Date:      2010-10-05 11:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/971c8132f5b2

6988836: A new JavacElements is created for each round of annotation processing
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/model/JavacElements.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/tools/javac/processing/environment/round/TestContext.java

Changeset: 33603a5fa84d
Author:    jjg
Date:      2010-10-05 17:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/33603a5fa84d

6893932: javah help screen lists -h and -? but does not accept them
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javah/JavahTask.java
+ test/tools/javah/TestHelpOpts.java

Changeset: c8b4a1e76089
Author:    jjg
Date:      2010-10-07 15:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/c8b4a1e76089

6990379: two examples fail under CheckExamples on Windows
Reviewed-by: darcy

! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/FileManager.java

Changeset: 5b5d965900b8
Author:    jjg
Date:      2010-10-11 10:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/5b5d965900b8

6990390: javah -help produces help screen with extraneous output
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javah/resources/l10n.properties
! test/tools/javah/TestHelpOpts.java

Changeset: 68cf07910d74
Author:    jjg
Date:      2010-10-12 12:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/68cf07910d74

6989457: javadoc test file test/tools/javadoc/T4994049/FileWithTabs.java probably does not
Reviewed-by: mcimadamore

! test/tools/javadoc/T4994049/FileWithTabs.java
! test/tools/javadoc/T4994049/T4994049.java

Changeset: 14a707f8ce84
Author:    jjg
Date:      2010-10-12 13:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/14a707f8ce84

6988407: javac crashes running processor on errant code; it used to print error message
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! test/tools/javac/api/6406133/Erroneous.java
+ test/tools/javac/processing/errors/TestParseErrors/ParseErrors.java
+ test/tools/javac/processing/errors/TestParseErrors/TestParseErrors.java
+ test/tools/javac/processing/errors/TestParseErrors/TestParseErrors.out

Changeset: a1d31ab7b525
Author:    jjg
Date:      2010-10-12 13:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/a1d31ab7b525

4942232: missing param class processes without error
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javah/JNI.java
! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/com/sun/tools/javah/LLNI.java
! src/share/classes/com/sun/tools/javah/Mangle.java
! src/share/classes/com/sun/tools/javah/TypeSignature.java
! src/share/classes/com/sun/tools/javah/resources/l10n.properties
+ test/tools/javah/4942232/ParamClassTest.java
+ test/tools/javah/4942232/Test.java

Changeset: ea92d1e275b6
Author:    jjg
Date:      2010-10-12 14:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/ea92d1e275b6

6990133: AnnotationProxyMaker.ValueVisitor$1 contains non-transient non-serializable field
Reviewed-by: darcy

! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java

Changeset: ee366cc698c0
Author:    jjg
Date:      2010-10-12 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/ee366cc698c0

6908476: test/tools/javac/T6705935.java fails if non-zip files found on platform class path
Reviewed-by: darcy

! test/tools/javac/T6705935.java

Changeset: 9bfb0e6fd526
Author:    lana
Date:      2010-10-13 17:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/9bfb0e6fd526

Merge


Changeset: 493ecc8111ba
Author:    mcimadamore
Date:      2010-10-18 19:14 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/493ecc8111ba

6991980: polymorphic signature calls don't share the same CP entries
Summary: wrong use of attr env in Infer.java prevents sharing of CP entries for PS calls
Reviewed-by: darcy, jrose

! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/meth/TestCP.java

Changeset: 2187e78b7980
Author:    lana
Date:      2010-10-18 21:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2187e78b7980

Merge


Changeset: 857bfcea3f30
Author:    lana
Date:      2010-10-26 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/857bfcea3f30

Merge


Changeset: 2129a046f117
Author:    cl
Date:      2010-10-28 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2129a046f117

Added tag jdk7-b116 for changeset 857bfcea3f30

! .hgtags

Changeset: 5bb96781fb58
Author:    cl
Date:      2010-11-04 15:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/5bb96781fb58

Added tag jdk7-b117 for changeset 2129a046f117

! .hgtags

Changeset: 5286a99de2e6
Author:    sundar
Date:      2010-10-19 11:47 +0530
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/5286a99de2e6

6551367: javadoc throws ClassCastException when an @link tries to reference constructor.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
+ test/tools/javadoc/T6551367.java

Changeset: 4851ff2ffc10
Author:    jjg
Date:      2010-10-19 15:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4851ff2ffc10

6987760: remove 308 support from JDK7
Reviewed-by: darcy, mcimadamore

- src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java
! src/share/classes/com/sun/source/tree/MethodTree.java
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/tree/TreeVisitor.java
! src/share/classes/com/sun/source/tree/TypeParameterTree.java
- src/share/classes/com/sun/source/util/AbstractTypeProcessor.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
- test/tools/javac/T6985181.java
! test/tools/javac/annotations/6881115/T6881115.java
! test/tools/javac/annotations/6881115/T6881115.out
- test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/tree/TreePosTest.java
- test/tools/javac/treeannotests/AnnoTreeTests.java
- test/tools/javac/typeAnnotations/6967002/T6967002.java
- test/tools/javac/typeAnnotations/6967002/T6967002.out
- test/tools/javac/typeAnnotations/InnerClass.java
- test/tools/javac/typeAnnotations/MultipleTargets.java
- test/tools/javac/typeAnnotations/TypeParameterTarget.java
- test/tools/javac/typeAnnotations/TypeUseTarget.java
- test/tools/javac/typeAnnotations/attribution/Scopes.java
- test/tools/javac/typeAnnotations/classfile/DeadCode.java
- test/tools/javac/typeAnnotations/failures/AnnotationVersion.java
- test/tools/javac/typeAnnotations/failures/AnnotationVersion.out
- test/tools/javac/typeAnnotations/failures/IncompleteArray.java
- test/tools/javac/typeAnnotations/failures/IncompleteArray.out
- test/tools/javac/typeAnnotations/failures/IncompleteVararg.java
- test/tools/javac/typeAnnotations/failures/IncompleteVararg.out
- test/tools/javac/typeAnnotations/failures/IndexArray.java
- test/tools/javac/typeAnnotations/failures/IndexArray.out
- test/tools/javac/typeAnnotations/failures/LintCast.java
- test/tools/javac/typeAnnotations/failures/LintCast.out
- test/tools/javac/typeAnnotations/failures/OldArray.java
- test/tools/javac/typeAnnotations/failures/Scopes.java
- test/tools/javac/typeAnnotations/failures/Scopes.out
- test/tools/javac/typeAnnotations/failures/StaticFields.java
- test/tools/javac/typeAnnotations/failures/StaticFields.out
- test/tools/javac/typeAnnotations/failures/StaticMethods.java
- test/tools/javac/typeAnnotations/failures/StaticMethods.out
- test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/target/Constructor.java
- test/tools/javac/typeAnnotations/failures/target/Constructor.out
- test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java
- test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out
- test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java
- test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out
- test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java
- test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out
- test/tools/javac/typeAnnotations/failures/target/VoidMethod.java
- test/tools/javac/typeAnnotations/failures/target/VoidMethod.out
! test/tools/javac/typeAnnotations/newlocations/BasicTest.java
+ test/tools/javac/typeAnnotations/newlocations/BasicTest.out
- test/tools/javac/typeAnnotations/newlocations/ClassExtends.java
- test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java
- test/tools/javac/typeAnnotations/newlocations/ClassParameters.java
- test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java
- test/tools/javac/typeAnnotations/newlocations/Expressions.java
- test/tools/javac/typeAnnotations/newlocations/Fields.java
- test/tools/javac/typeAnnotations/newlocations/LocalVariables.java
- test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java
- test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java
- test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java
- test/tools/javac/typeAnnotations/newlocations/Parameters.java
- test/tools/javac/typeAnnotations/newlocations/Receivers.java
- test/tools/javac/typeAnnotations/newlocations/Throws.java
- test/tools/javac/typeAnnotations/newlocations/TypeCasts.java
- test/tools/javac/typeAnnotations/newlocations/TypeParameters.java
- test/tools/javac/typeAnnotations/newlocations/Wildcards.java
- test/tools/javap/typeAnnotations/ArrayClassLiterals.java
- test/tools/javap/typeAnnotations/ArrayClassLiterals2.java
- test/tools/javap/typeAnnotations/ClassLiterals.java
- test/tools/javap/typeAnnotations/JSR175Annotations.java
- test/tools/javap/typeAnnotations/NewArray.java
- test/tools/javap/typeAnnotations/Presence.java
- test/tools/javap/typeAnnotations/PresenceInner.java
- test/tools/javap/typeAnnotations/T6855990.java
- test/tools/javap/typeAnnotations/Visibility.java

Changeset: 01eabcd240e9
Author:    jjg
Date:      2010-10-22 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/01eabcd240e9

6993301: catch parameters do not have correct kind (i.e. ElementKind.EXCEPTION_PARAMETER)
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/T6993301.java

Changeset: 7755f47542a0
Author:    jjg
Date:      2010-10-26 14:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/7755f47542a0

6949587: rename "DisjointType" to "DisjunctType"
Reviewed-by: mcimadamore

- src/share/classes/com/sun/source/tree/DisjointTypeTree.java
+ src/share/classes/com/sun/source/tree/DisjunctiveTypeTree.java
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/tree/TreeVisitor.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/javac/code/Flags.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/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java

Changeset: 601160d857ef
Author:    jjg
Date:      2010-10-28 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/601160d857ef

6460352: Reintroduce Scope.dble
Reviewed-by: mcimadamore, jjg
Contributed-by: per.bothner at oracle.com

! src/share/classes/com/sun/tools/javac/code/Scope.java

Changeset: 2974d3800eb1
Author:    jjg
Date:      2010-10-28 18:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2974d3800eb1

6994946: option to specify only syntax errors as unrecoverable
Reviewed-by: darcy, mcimadamore

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/AbstractLog.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
+ test/tools/javac/processing/6994946/SemanticErrorTest.1.out
+ test/tools/javac/processing/6994946/SemanticErrorTest.2.out
+ test/tools/javac/processing/6994946/SemanticErrorTest.java
+ test/tools/javac/processing/6994946/SyntaxErrorTest.java
+ test/tools/javac/processing/6994946/SyntaxErrorTest.out
+ test/tools/javac/processing/6994946/TestProcessor.java

Changeset: 460b2f588d0d
Author:    jjg
Date:      2010-10-29 12:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/460b2f588d0d

6993304: JavacTrees.getAttrContext not updated to Tree.Kind.{ANNOTATION_TYPE,ENUM,INTERFACE}
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java

Changeset: 895bea45a3e8
Author:    jjg
Date:      2010-10-29 13:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/895bea45a3e8

6994608: javah no longer accepts parameter files as input
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/com/sun/tools/javah/resources/l10n.properties
+ test/tools/javah/T6994608.java

Changeset: 6ce6ee1b831a
Author:    jjg
Date:      2010-11-01 19:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/6ce6ee1b831a

6996626: Scope fix issues for ImportScope
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Scope.java

Changeset: 20659c8c917d
Author:    mcimadamore
Date:      2010-11-02 12:00 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/20659c8c917d

6996415: Override bridges causes compiler-generated code to end up with synthetic infinite loop
Summary: temporarily disable fix for override bridges (6337171)
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! test/tools/javac/generics/OverrideBridge.java

Changeset: fadc6d3e63f4
Author:    mcimadamore
Date:      2010-11-02 12:01 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/fadc6d3e63f4

6939780: add a warning to detect diamond sites
Summary: added hidden compiler flag '-XDfindDiamond' to detect 'diamondifiable' sites
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/DiamondRedundantArgs.java
+ test/tools/javac/diags/examples/DiamondRedundantArgs1.java
+ test/tools/javac/generics/diamond/T6939780.java
+ test/tools/javac/generics/diamond/T6939780.out

Changeset: 534afdc92cdc
Author:    lana
Date:      2010-11-02 19:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/534afdc92cdc

Merge

- src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java
- src/share/classes/com/sun/source/tree/DisjointTypeTree.java
- src/share/classes/com/sun/source/util/AbstractTypeProcessor.java
- test/tools/javac/T6985181.java
- test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java
- test/tools/javac/treeannotests/AnnoTreeTests.java
- test/tools/javac/typeAnnotations/6967002/T6967002.java
- test/tools/javac/typeAnnotations/6967002/T6967002.out
- test/tools/javac/typeAnnotations/InnerClass.java
- test/tools/javac/typeAnnotations/MultipleTargets.java
- test/tools/javac/typeAnnotations/TypeParameterTarget.java
- test/tools/javac/typeAnnotations/TypeUseTarget.java
- test/tools/javac/typeAnnotations/attribution/Scopes.java
- test/tools/javac/typeAnnotations/classfile/DeadCode.java
- test/tools/javac/typeAnnotations/failures/AnnotationVersion.java
- test/tools/javac/typeAnnotations/failures/AnnotationVersion.out
- test/tools/javac/typeAnnotations/failures/IncompleteArray.java
- test/tools/javac/typeAnnotations/failures/IncompleteArray.out
- test/tools/javac/typeAnnotations/failures/IncompleteVararg.java
- test/tools/javac/typeAnnotations/failures/IncompleteVararg.out
- test/tools/javac/typeAnnotations/failures/IndexArray.java
- test/tools/javac/typeAnnotations/failures/IndexArray.out
- test/tools/javac/typeAnnotations/failures/LintCast.java
- test/tools/javac/typeAnnotations/failures/LintCast.out
- test/tools/javac/typeAnnotations/failures/OldArray.java
- test/tools/javac/typeAnnotations/failures/Scopes.java
- test/tools/javac/typeAnnotations/failures/Scopes.out
- test/tools/javac/typeAnnotations/failures/StaticFields.java
- test/tools/javac/typeAnnotations/failures/StaticFields.out
- test/tools/javac/typeAnnotations/failures/StaticMethods.java
- test/tools/javac/typeAnnotations/failures/StaticMethods.out
- test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/target/Constructor.java
- test/tools/javac/typeAnnotations/failures/target/Constructor.out
- test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java
- test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out
- test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java
- test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out
- test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java
- test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out
- test/tools/javac/typeAnnotations/failures/target/VoidMethod.java
- test/tools/javac/typeAnnotations/failures/target/VoidMethod.out
- test/tools/javac/typeAnnotations/newlocations/ClassExtends.java
- test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java
- test/tools/javac/typeAnnotations/newlocations/ClassParameters.java
- test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java
- test/tools/javac/typeAnnotations/newlocations/Expressions.java
- test/tools/javac/typeAnnotations/newlocations/Fields.java
- test/tools/javac/typeAnnotations/newlocations/LocalVariables.java
- test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java
- test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java
- test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java
- test/tools/javac/typeAnnotations/newlocations/Parameters.java
- test/tools/javac/typeAnnotations/newlocations/Receivers.java
- test/tools/javac/typeAnnotations/newlocations/Throws.java
- test/tools/javac/typeAnnotations/newlocations/TypeCasts.java
- test/tools/javac/typeAnnotations/newlocations/TypeParameters.java
- test/tools/javac/typeAnnotations/newlocations/Wildcards.java
- test/tools/javap/typeAnnotations/ArrayClassLiterals.java
- test/tools/javap/typeAnnotations/ArrayClassLiterals2.java
- test/tools/javap/typeAnnotations/ClassLiterals.java
- test/tools/javap/typeAnnotations/JSR175Annotations.java
- test/tools/javap/typeAnnotations/NewArray.java
- test/tools/javap/typeAnnotations/Presence.java
- test/tools/javap/typeAnnotations/PresenceInner.java
- test/tools/javap/typeAnnotations/T6855990.java
- test/tools/javap/typeAnnotations/Visibility.java

Changeset: c491eec0acc7
Author:    lana
Date:      2010-11-09 22:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/c491eec0acc7

Merge

- src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java
- src/share/classes/com/sun/source/tree/DisjointTypeTree.java
- src/share/classes/com/sun/source/util/AbstractTypeProcessor.java
- test/tools/javac/T6985181.java
- test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java
- test/tools/javac/treeannotests/AnnoTreeTests.java
- test/tools/javac/typeAnnotations/6967002/T6967002.java
- test/tools/javac/typeAnnotations/6967002/T6967002.out
- test/tools/javac/typeAnnotations/InnerClass.java
- test/tools/javac/typeAnnotations/MultipleTargets.java
- test/tools/javac/typeAnnotations/TypeParameterTarget.java
- test/tools/javac/typeAnnotations/TypeUseTarget.java
- test/tools/javac/typeAnnotations/attribution/Scopes.java
- test/tools/javac/typeAnnotations/classfile/DeadCode.java
- test/tools/javac/typeAnnotations/failures/AnnotationVersion.java
- test/tools/javac/typeAnnotations/failures/AnnotationVersion.out
- test/tools/javac/typeAnnotations/failures/IncompleteArray.java
- test/tools/javac/typeAnnotations/failures/IncompleteArray.out
- test/tools/javac/typeAnnotations/failures/IncompleteVararg.java
- test/tools/javac/typeAnnotations/failures/IncompleteVararg.out
- test/tools/javac/typeAnnotations/failures/IndexArray.java
- test/tools/javac/typeAnnotations/failures/IndexArray.out
- test/tools/javac/typeAnnotations/failures/LintCast.java
- test/tools/javac/typeAnnotations/failures/LintCast.out
- test/tools/javac/typeAnnotations/failures/OldArray.java
- test/tools/javac/typeAnnotations/failures/Scopes.java
- test/tools/javac/typeAnnotations/failures/Scopes.out
- test/tools/javac/typeAnnotations/failures/StaticFields.java
- test/tools/javac/typeAnnotations/failures/StaticFields.out
- test/tools/javac/typeAnnotations/failures/StaticMethods.java
- test/tools/javac/typeAnnotations/failures/StaticMethods.out
- test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out
- test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java
- test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out
- test/tools/javac/typeAnnotations/failures/target/Constructor.java
- test/tools/javac/typeAnnotations/failures/target/Constructor.out
- test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java
- test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out
- test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java
- test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out
- test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java
- test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out
- test/tools/javac/typeAnnotations/failures/target/VoidMethod.java
- test/tools/javac/typeAnnotations/failures/target/VoidMethod.out
- test/tools/javac/typeAnnotations/newlocations/ClassExtends.java
- test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java
- test/tools/javac/typeAnnotations/newlocations/ClassParameters.java
- test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java
- test/tools/javac/typeAnnotations/newlocations/Expressions.java
- test/tools/javac/typeAnnotations/newlocations/Fields.java
- test/tools/javac/typeAnnotations/newlocations/LocalVariables.java
- test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java
- test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java
- test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java
- test/tools/javac/typeAnnotations/newlocations/Parameters.java
- test/tools/javac/typeAnnotations/newlocations/Receivers.java
- test/tools/javac/typeAnnotations/newlocations/Throws.java
- test/tools/javac/typeAnnotations/newlocations/TypeCasts.java
- test/tools/javac/typeAnnotations/newlocations/TypeParameters.java
- test/tools/javac/typeAnnotations/newlocations/Wildcards.java
- test/tools/javap/typeAnnotations/ArrayClassLiterals.java
- test/tools/javap/typeAnnotations/ArrayClassLiterals2.java
- test/tools/javap/typeAnnotations/ClassLiterals.java
- test/tools/javap/typeAnnotations/JSR175Annotations.java
- test/tools/javap/typeAnnotations/NewArray.java
- test/tools/javap/typeAnnotations/Presence.java
- test/tools/javap/typeAnnotations/PresenceInner.java
- test/tools/javap/typeAnnotations/T6855990.java
- test/tools/javap/typeAnnotations/Visibility.java

Changeset: 814561077c44
Author:    cl
Date:      2010-11-11 11:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/814561077c44

Added tag jdk7-b118 for changeset c491eec0acc7

! .hgtags

Changeset: f2048d9c666e
Author:    mcimadamore
Date:      2010-11-04 12:57 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f2048d9c666e

6993963: Project Coin: Use precise exception analysis for effectively final catch parameters
Summary: More precise rethrow analysis should be extended to effectively-final exception parameters. Multicatch parameters should be made implicitly final.
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/code/Flags.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
- test/tools/javac/diags/examples/MulticatchMustBeFinal.java
+ test/tools/javac/multicatch/Neg01eff_final.java
+ test/tools/javac/multicatch/Neg01eff_final.out
! test/tools/javac/multicatch/Neg02.java
! test/tools/javac/multicatch/Neg02.out
+ test/tools/javac/multicatch/Neg02eff_final.java
+ test/tools/javac/multicatch/Neg02eff_final.out
! test/tools/javac/multicatch/Neg03.java
! test/tools/javac/multicatch/Neg03.out
+ test/tools/javac/multicatch/Neg04eff_final.java
+ test/tools/javac/multicatch/Neg04eff_final.out
+ test/tools/javac/multicatch/Neg05.java
+ test/tools/javac/multicatch/Neg05.out
+ test/tools/javac/multicatch/Pos06.java
+ test/tools/javac/multicatch/Pos07.java
+ test/tools/javac/multicatch/model/Check.java
+ test/tools/javac/multicatch/model/Member.java
+ test/tools/javac/multicatch/model/Model01.java
+ test/tools/javac/multicatch/model/ModelChecker.java

Changeset: e9e41c88b03e
Author:    mcimadamore
Date:      2010-11-04 12:58 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/e9e41c88b03e

6714835: Safe cast is rejected (with warning) by javac
Summary: Rules for unchecked cast conversion do not take into account type-containment
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! test/tools/javac/cast/6467183/T6467183a.out
+ test/tools/javac/cast/6714835/T6714835.java
+ test/tools/javac/cast/6714835/T6714835.out

Changeset: e406f0645b7e
Author:    lana
Date:      2010-11-04 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/e406f0645b7e

Merge


Changeset: 9427a3c795fc
Author:    jjg
Date:      2010-11-06 13:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/9427a3c795fc

6998063: new Scope impl to fix Scope performance issues
Reviewed-by: jjg
Contributed-by: per.bothner at oracle.com

! src/share/classes/com/sun/tools/javac/code/Scope.java
+ test/tools/javac/6996626/Main.java
+ test/tools/javac/6996626/pack1/Symbol.java

Changeset: a0d9d642f65b
Author:    jjg
Date:      2010-11-09 17:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/a0d9d642f65b

6997958: test tools/javac/api/T6412669.java fails in PIT
Reviewed-by: darcy

! test/tools/javac/api/T6412669.java

Changeset: bce19889597e
Author:    mcimadamore
Date:      2010-11-10 12:37 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/bce19889597e

6996914: Diamond inference: problem when accessing protected constructor
Summary: special resolution scheme for diamond inference needs to open up protected constructors in anon inner class creation
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/generics/diamond/6996914/T6996914a.java
+ test/tools/javac/generics/diamond/6996914/T6996914b.java

Changeset: 58ceeff50af8
Author:    mcimadamore
Date:      2010-11-12 12:32 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/58ceeff50af8

6598108: com.sun.source.util.Trees.isAccessible incorrect
Summary: JavacTrees' version of isAccessible should take into account enclosing class accessibility
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/api/6598108/T6598108.java

Changeset: fdc67f5170e9
Author:    mcimadamore
Date:      2010-11-12 12:33 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/fdc67f5170e9

6999067: cast for invokeExact call gets redundant cast to <type> warnings
Summary: Xlint:cast should not report cast used in order to specify target type in polymorphic signature calls
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Flow.java
+ test/tools/javac/meth/XlintWarn.java

Changeset: 6a99b741a1b0
Author:    mcimadamore
Date:      2010-11-12 12:34 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/6a99b741a1b0

6970016: Clean up ARM/try-with-resources implementation
Summary: changed Xlint option name from -Xlint:arm to -Xlint:try
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Lint.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
- test/tools/javac/TryWithResources/ArmLint.java
- test/tools/javac/TryWithResources/ArmLint.out
! test/tools/javac/TryWithResources/ImplicitFinal.out
+ test/tools/javac/TryWithResources/TwrLint.java
+ test/tools/javac/TryWithResources/TwrLint.out
! test/tools/javac/TryWithResources/TwrOnNonResource.out
! test/tools/javac/diags/examples/ResourceClosed.java
! test/tools/javac/diags/examples/ResourceMayNotBeAssigned.java
! test/tools/javac/diags/examples/ResourceNotApplicableToType.java
! test/tools/javac/diags/examples/ResourceNotReferenced.java
! test/tools/javac/diags/examples/TryResourceNotSupported.java

Changeset: a7faadc252c8
Author:    lana
Date:      2010-11-13 19:00 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/a7faadc252c8

Merge


Changeset: 4328728e0409
Author:    darcy
Date:      2010-11-14 07:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4328728e0409

6991528: Support making Throwable.suppressedExceptions immutable
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/util/Names.java
! test/tools/javac/TryWithResources/TwrSuppression.java
! test/tools/javac/TryWithResources/TwrTests.java

Changeset: a7ea58fa3e9a
Author:    mcimadamore
Date:      2010-11-15 13:50 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/a7ea58fa3e9a

6985719: Alike methods in interfaces (Inheritance and Overriding)
Summary: javac should report error when interface inherits unrelated method with same erasure
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/6985719/T6985719a.java
+ test/tools/javac/generics/6985719/T6985719a.out
+ test/tools/javac/generics/6985719/T6985719b.java
+ test/tools/javac/generics/6985719/T6985719b.out
+ test/tools/javac/generics/6985719/T6985719c.java
+ test/tools/javac/generics/6985719/T6985719c.out
+ test/tools/javac/generics/6985719/T6985719d.java
+ test/tools/javac/generics/6985719/T6985719d.out
+ test/tools/javac/generics/6985719/T6985719e.java
+ test/tools/javac/generics/6985719/T6985719e.out
+ test/tools/javac/generics/6985719/T6985719f.java
+ test/tools/javac/generics/6985719/T6985719f.out
+ test/tools/javac/generics/6985719/T6985719g.java
+ test/tools/javac/generics/6985719/T6985719g.out
+ test/tools/javac/generics/6985719/T6985719h.java
+ test/tools/javac/generics/6985719/T6985719h.out

Changeset: 1dd813a529cf
Author:    mcimadamore
Date:      2010-11-15 14:41 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/1dd813a529cf

6999635: Multicatch: crash while compiling simple code with a multicatch parameter
Summary: missing erasure when computing stackmaps leads to assertion error
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
+ test/tools/javac/multicatch/Pos08.java
+ test/tools/javac/multicatch/Pos08eff_final.java

Changeset: 621e096ca843
Author:    cl
Date:      2010-12-02 19:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/621e096ca843

Added tag jdk7-b120 for changeset 1dd813a529cf

! .hgtags


From Dmitry.Samersoff at oracle.com  Fri Dec  3 06:13:42 2010
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 03 Dec 2010 17:13:42 +0300
Subject: Review request (S): 6539281 -Xcheck:jni should validate char*
	argument to ReleaseStringUTFChars
In-Reply-To: <3441BF30-5C1A-4F0C-BB45-FF7006064106@oracle.com>
References: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>	<4CF7D382.6050309@oracle.com>
	<3441BF30-5C1A-4F0C-BB45-FF7006064106@oracle.com>
Message-ID: <4CF8FB16.2090306@oracle.com>

Staffan,

My main concern that clients often claim that check_jni is too heavy to 
use it with more-or less loaded application, but we are adding extra 
allocation/copying to one of the most often used JNI call.

Moreover we already copy string two times inside GetStringUTFChars - so 
your copying is the third one.

IMHO we should avoid extra memory manipulations when possible ever at 
the cost of some code duplication.

With non utf string it's easy - just copy part of code from 
GetStringChars replacing copy to compare (see attachment), for UTF it 
also possible but require some experiments before sending to alias ...

-Dmitry







On 2010-12-02 22:11, Staffan Larsen wrote:
> Dmitry,
>
> 1) Yes, I agree. But for ReleaseStringUTFChars a similar check would require a UTF conversion which I'd like to avoid. And I prefer to have similar code in both the UTF and non-UTF case. It has been suggested that the similiar code should be abstracted into some helper method, but I can't figure a way that doesn't make the code more complex and harder to read.
>
> 2) Any ideas?
>
> 3) Yes, "chars" should definitely be NULL-checked.
>
> Thanks,
> /Staffan
>
> On 2 dec 2010, at 18.12, Dmitry Samersoff wrote:
>
>> Staffan,
>>
>> 1. Logically string argument of GetStringChars and ReleaseStringChars have to be the same.
>>   So:
>>     checked_jni_ReleaseStringChars:
>>        chars_to_check = GetStringChars(env,str,isCopy);
>>        memcmp(chars,chars_to_check, len>  10 ? 10 : len);
>>
>> could be a better approach.
>>
>> BUT:
>>
>> 2.
>> As far as I know GetStringChars do alloc/memcpy inside it
>> Could we avoid extra copying?
>>
>> 3.
>> Code below:
>> jint *tagLocation = ((jint*) chars) - 1;
>>
>> Could lead to cryptic crash e.g. if we pass 0 as a char (common case) to this code we will have a crash on read from 0xFFFFFFFF rather than much more clean crash on zero-access. So either gurantee chars != 0 have to be there or tag should be placed at the end of chars, after terminating zero.
>>
>> -Dmitry
>>
>>
>>
>> On 2010-12-02 17:18, Staffan Larsen wrote:
>>> http://cr.openjdk.java.net/~sla/6539281/webrev.00/
>>>
>>> Validate that ReleaseStringUTFChars/ReleaseStringChars is called with
>>> something allocated by GetStringUTChars/GetStringChars when running with
>>> -Xcheck:jni. This is accomplished by adding a well-known tag in the
>>> memory immediately before the pointer that is returned to the user. This
>>> tag is verified in ReleaseStringUTFChars.
>>>
>>> Thanks,
>>>
>>> /Staffan
>>>
>>
>>
>> --
>> Dmitry Samersoff
>> J2SE Sustaining team, SPB04
>> * Give Rabbit time and he'll always get the answer ...
>


-- 
Dmitry Samersoff
J2SE Sustaining team, SPB04
* Give Rabbit time and he'll always get the answer ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: is_good_string_proposed.cpp
Type: text/x-c
Size: 732 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101203/c15cae49/attachment.bin 

From stefan.karlsson at oracle.com  Fri Dec  3 07:57:59 2010
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Fri, 03 Dec 2010 15:57:59 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20101203155802.DAB5847077@hg.openjdk.java.net>

Changeset: c760f78e0a53
Author:    stefank
Date:      2010-12-01 15:04 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c760f78e0a53

7003125: precompiled.hpp is included when precompiled headers are not used
Summary: Added an ifndef DONT_USE_PRECOMPILED_HEADER to precompiled.hpp. Set up DONT_USE_PRECOMPILED_HEADER when compiling with Sun Studio or when the user specifies USE_PRECOMPILED_HEADER=0. Fixed broken include dependencies.
Reviewed-by: coleenp, kvn

! make/linux/makefiles/gcc.make
! make/linux/makefiles/sparcWorks.make
! make/solaris/makefiles/gcc.make
! make/solaris/makefiles/sparcWorks.make
! make/windows/makefiles/debug.make
! make/windows/makefiles/fastdebug.make
! make/windows/makefiles/product.make
! make/windows/makefiles/vm.make
! src/share/vm/ci/ciCallProfile.hpp
! src/share/vm/ci/ciMethodHandle.hpp
! src/share/vm/classfile/placeholders.hpp
! src/share/vm/code/vtableStubs.hpp
! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp
! src/share/vm/interpreter/oopMapCache.hpp
! src/share/vm/libadt/vectset.cpp
! src/share/vm/memory/threadLocalAllocBuffer.inline.hpp
! src/share/vm/precompiled.hpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/prims/jvmtiImpl.hpp
! src/share/vm/runtime/objectMonitor.hpp

Changeset: 2968675b413e
Author:    stefank
Date:      2010-12-02 20:01 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2968675b413e

7003786: sort Obj_Files before compiling
Summary: Reverted to old sort order on Linux and Solaris.
Reviewed-by: tonyp, coleenp

! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make


From staffan.larsen at oracle.com  Fri Dec  3 12:16:59 2010
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Fri, 03 Dec 2010 20:16:59 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6981484: Update development launcher
Message-ID: <20101203201701.0908847085@hg.openjdk.java.net>

Changeset: cb2d0a362639
Author:    sla
Date:      2010-12-02 05:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/cb2d0a362639

6981484: Update development launcher
Summary: Add new development launcher called hotspot(.exe)
Reviewed-by: coleenp

! make/linux/makefiles/launcher.make
! make/solaris/makefiles/launcher.make
! make/windows/makefiles/debug.make
! make/windows/makefiles/fastdebug.make
+ make/windows/makefiles/launcher.make
! make/windows/makefiles/product.make
- src/os/linux/launcher/java.c
- src/os/linux/launcher/java.h
- src/os/linux/launcher/java_md.c
- src/os/linux/launcher/java_md.h
+ src/os/posix/launcher/java_md.c
+ src/os/posix/launcher/java_md.h
+ src/os/posix/launcher/launcher.script
- src/os/solaris/launcher/java.c
- src/os/solaris/launcher/java.h
- src/os/solaris/launcher/java_md.c
- src/os/solaris/launcher/java_md.h
+ src/os/windows/launcher/java_md.c
+ src/os/windows/launcher/java_md.h
! src/os/windows/vm/os_windows.cpp
+ src/share/tools/launcher/java.c
+ src/share/tools/launcher/java.h
+ src/share/tools/launcher/jli_util.c
+ src/share/tools/launcher/jli_util.h
+ src/share/tools/launcher/wildcard.c
+ src/share/tools/launcher/wildcard.h
! src/share/vm/prims/jvm.h


From coleen.phillimore at oracle.com  Sat Dec  4 11:39:31 2010
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Sat, 04 Dec 2010 19:39:31 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6704010: Internal Error
	(src/share/vm/interpreter/interpreterRuntime.cpp:1106)
Message-ID: <20101204193934.1B114470F3@hg.openjdk.java.net>

Changeset: 9bc798875b2a
Author:    coleenp
Date:      2010-12-04 00:09 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9bc798875b2a

6704010: Internal Error (src/share/vm/interpreter/interpreterRuntime.cpp:1106)
Summary: Fixed a race condition in the assertion caused by an unguarded, concurrent access to a GrowableArray object.
Reviewed-by: coleenp, dholmes, dsamersoff
Contributed-by: volker.simonis at gmail.com

! src/share/vm/interpreter/interpreterRuntime.cpp


From staffan.larsen at oracle.com  Mon Dec  6 00:32:52 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 6 Dec 2010 00:32:52 -0800 (PST)
Subject: Review request (S): 6539281 -Xcheck:jni should validate char*
	argument to ReleaseStringUTFChars
In-Reply-To: <4CF8FB16.2090306@oracle.com>
References: <7d806b2f-57e2-4f22-b97e-95c94e70e2b7@default>
	<4CF7D382.6050309@oracle.com>
	<3441BF30-5C1A-4F0C-BB45-FF7006064106@oracle.com
	4CF8FB16.2090306@oracle.com>
Message-ID: <b54ddf40-947f-4b83-836e-a35e65e6357d@default>

Update webrev: http://cr.openjdk.java.net/~sla/6539281/webrev.01/

Changes in this version:

1) Use "const jint" instead of "#define".

2) GetStringChars/GetStringUTFChars: assert that 'isCopy' == JNI_TRUE

3) ReleaseStringChars/ReleaseStringUTFChars: check 'chars' for NULL

4) GetStringUTFChars : To reduce copying I added a method java_lang_String::as_utf8_string which takes a pre-allocated buffer. Thus, the number of copies for unchecked JNI is reduced to one (previously two) and two for checked JNI (previously three). This could potentially speed up unchecked JNI if GetStringUTFChars is heavily used.

Thanks,
/Staffan

From coleen.phillimore at oracle.com  Mon Dec  6 16:05:22 2010
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 07 Dec 2010 00:05:22 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 4 new changesets
Message-ID: <20101207000529.C9C2B4717D@hg.openjdk.java.net>

Changeset: 631f79e71e90
Author:    tonyp
Date:      2010-08-24 17:24 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/631f79e71e90

6974966: G1: unnecessary direct-to-old allocations
Summary: This change revamps the slow allocation path of G1. Improvements include the following: a) Allocations directly to old regions are now totally banned. G1 now only allows allocations out of young regions (with the only exception being humongous regions). b) The thread that allocates a new region (which is now guaranteed to be young) does not dirty all its cards. Each thread that successfully allocates out of a young region is now responsible for dirtying the cards that corresponding to the "block" that just got allocated. c) allocate_new_tlab() and mem_allocate() are now implemented differently and TLAB allocations are only done by allocate_new_tlab(). d) If a thread schedules an evacuation pause in order to satisfy an allocation request, it will perform the allocation at the end of the safepoint so that the thread that initiated the GC also gets "first pick" of any space made available by the GC. e) If a thread is unable to allocate a humongous object it will schedul
 e an evacuation pause in case it reclaims enough regions so that the humongous allocation can be satisfied aftewards. f) The G1 policy is more careful to set the young list target length to be the survivor number +1. g) Lots of code tidy up, removal, refactoring to make future changes easier.
Reviewed-by: johnc, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp

Changeset: fd1d227ef1b9
Author:    johnc
Date:      2010-12-01 17:34 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fd1d227ef1b9

6983204: G1: Nightly test nsk/regression/b4958615 failing with +ExplicitGCInvokesConcurrent
Summary: Enable reference discovery during concurrent marking by setting the reference processor field of the concurrent marking closure. Keep reference objects on the discovered reference lists alive during incremental evacuation pauses until they are processed at the end of concurrent marking.
Reviewed-by: ysr, tonyp

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/runtime/thread.hpp

Changeset: d9310331a29c
Author:    tonyp
Date:      2010-12-02 13:20 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d9310331a29c

7003860: G1: assert(_cur_alloc_region == NULL || !expect_null_cur_alloc_region) fails
Summary: Wrong assumption about expecting the current alloc region expected to be NULL in expand_and_allocate().
Reviewed-by: brutisso, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 42f65821fa4e
Author:    coleenp
Date:      2010-12-06 15:37 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/42f65821fa4e

Merge



From keith.mcguigan at oracle.com  Mon Dec  6 21:34:16 2010
From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com)
Date: Tue, 07 Dec 2010 05:34:16 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7003782: Update JVMTI version to 1.2 for
	jdk7
Message-ID: <20101207053418.0122B4718C@hg.openjdk.java.net>

Changeset: 684faacebf20
Author:    kamg
Date:      2010-12-06 20:21 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/684faacebf20

7003782: Update JVMTI version to 1.2 for jdk7
Summary: Update minor version to 1.2 for jdk7
Reviewed-by: phh, dcubed

! src/share/vm/prims/jvmti.xml
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/prims/jvmtiEnvBase.hpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiH.xsl


From David.Holmes at oracle.com  Tue Dec  7 03:26:52 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 07 Dec 2010 21:26:52 +1000
Subject: Small Request for review: 7005007 - Refine use of ALT_COMPILER_PATH
	to avoid conflict with JPRT usage
Message-ID: <4CFE19FC.3020001@oracle.com>

Simple fix to avoid conflicting use of ALT_COMPILER_PATH.

http://cr.openjdk.java.net/~dholmes/7005007/

Tested with JPRT linux builds and doing an internal cross-compile build.

Thanks,
David Holmes

From karen.kinnear at oracle.com  Tue Dec  7 05:15:41 2010
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 7 Dec 2010 08:15:41 -0500
Subject: Small Request for review: 7005007 - Refine use of
	ALT_COMPILER_PATH to avoid conflict with JPRT usage
In-Reply-To: <4CFE19FC.3020001@oracle.com>
References: <4CFE19FC.3020001@oracle.com>
Message-ID: <945A053A-71CF-4949-B599-1F63A0698C62@oracle.com>

David,

Looks good. Thanks for doing this.

thanks,
Karen

On Dec 7, 2010, at 6:26 AM, David Holmes wrote:

> Simple fix to avoid conflicting use of ALT_COMPILER_PATH.
>
> http://cr.openjdk.java.net/~dholmes/7005007/
>
> Tested with JPRT linux builds and doing an internal cross-compile  
> build.
>
> Thanks,
> David Holmes


From staffan.larsen at oracle.com  Tue Dec  7 06:01:49 2010
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Tue, 07 Dec 2010 14:01:49 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6539281: -Xcheck:jni should validate
	char* argument to ReleaseStringUTFChars
Message-ID: <20101207140151.D473C471A2@hg.openjdk.java.net>

Changeset: 017cd8bce8a8
Author:    sla
Date:      2010-12-07 03:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/017cd8bce8a8

6539281: -Xcheck:jni should validate char* argument to ReleaseStringUTFChars
Summary: Tag allocated memory with a magic value and verify when releasing.
Reviewed-by: phh, stefank

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.cpp


From kelly.ohair at oracle.com  Tue Dec  7 08:36:37 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 7 Dec 2010 08:36:37 -0800
Subject: Small Request for review: 7005007 - Refine use of
	ALT_COMPILER_PATH to avoid conflict with JPRT usage
In-Reply-To: <4CFE19FC.3020001@oracle.com>
References: <4CFE19FC.3020001@oracle.com>
Message-ID: <8041F16D-D0AE-40AD-B627-6FD79FE336C7@oracle.com>


On Dec 7, 2010, at 3:26 AM, David Holmes wrote:

> Simple fix to avoid conflicting use of ALT_COMPILER_PATH.
>
> http://cr.openjdk.java.net/~dholmes/7005007/
>
> Tested with JPRT linux builds and doing an internal cross-compile  
> build.
>
> Thanks,
> David Holmes

IF nm doesn't exist, then this shell script will fail, but return exit  
code 0, and the makefile
will not stop but create a bogus mapfile, which may or may not allow  
libjvm.so to link.
I think this shell script needs to use 'set -e' or do something like  
(nm || exit 1) | awk
or maybe both.  Can we fix this shell script?

In addition. I'd like to see some makefile verifications that the  
tools actually exist, something like

# Check fullpath tool
define filecheck # fullpath
$(if $(wildcard $1),$1,$(error "ERROR: File does not exist: $1"))
endef

# Check tools
ifdef CROSS_COMPILE_ARCH
   ifdef ALT_COMPILER_PATH
     CC      := $(call filecheck,$(ALT_COMPILER_PATH)/gcc)
     CPP    := $(call filecheck,$(ALT_COMPILER_PATH)/g++)
     NM     := $(call filecheck,$(ALT_COMPILER_PATH)/nm)
     STRIP := $(call filecheck,$(ALT_COMPILER_PATH)/strip)
   endif
endif

-----
We also need to make sure we document this in the README-builds.html  
file, but that can be
done some other time since it is in a different repository..

-kto


From David.Holmes at oracle.com  Tue Dec  7 13:53:02 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 08 Dec 2010 07:53:02 +1000
Subject: Small Request for review: 7005007 - Refine use of
	ALT_COMPILER_PATH to avoid conflict with JPRT usage
In-Reply-To: <945A053A-71CF-4949-B599-1F63A0698C62@oracle.com>
References: <4CFE19FC.3020001@oracle.com>
	<945A053A-71CF-4949-B599-1F63A0698C62@oracle.com>
Message-ID: <4CFEACBE.9010502@oracle.com>

Actually the change is gcc.make is not correct - I should have left it 
as-is - thanks Bob.

Will fix and resubmit.

Thanks for the review anyway.

David

Karen Kinnear said the following on 12/07/10 23:15:
> David,
> 
> Looks good. Thanks for doing this.
> 
> thanks,
> Karen
> 
> On Dec 7, 2010, at 6:26 AM, David Holmes wrote:
> 
>> Simple fix to avoid conflicting use of ALT_COMPILER_PATH.
>>
>> http://cr.openjdk.java.net/~dholmes/7005007/
>>
>> Tested with JPRT linux builds and doing an internal cross-compile build.
>>
>> Thanks,
>> David Holmes
> 

From David.Holmes at oracle.com  Tue Dec  7 13:54:05 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 08 Dec 2010 07:54:05 +1000
Subject: Small Request for review: 7005007 - Refine use of
	ALT_COMPILER_PATH to avoid conflict with JPRT usage
In-Reply-To: <8041F16D-D0AE-40AD-B627-6FD79FE336C7@oracle.com>
References: <4CFE19FC.3020001@oracle.com>
	<8041F16D-D0AE-40AD-B627-6FD79FE336C7@oracle.com>
Message-ID: <4CFEACFD.4020206@oracle.com>

Kelly,

I can file a RFE but repairing the build system is out of scope for this 
particular CR.

David

Kelly O'Hair said the following on 12/08/10 02:36:
> 
> On Dec 7, 2010, at 3:26 AM, David Holmes wrote:
> 
>> Simple fix to avoid conflicting use of ALT_COMPILER_PATH.
>>
>> http://cr.openjdk.java.net/~dholmes/7005007/
>>
>> Tested with JPRT linux builds and doing an internal cross-compile build.
>>
>> Thanks,
>> David Holmes
> 
> IF nm doesn't exist, then this shell script will fail, but return exit 
> code 0, and the makefile
> will not stop but create a bogus mapfile, which may or may not allow 
> libjvm.so to link.
> I think this shell script needs to use 'set -e' or do something like (nm 
> || exit 1) | awk
> or maybe both.  Can we fix this shell script?
> 
> In addition. I'd like to see some makefile verifications that the tools 
> actually exist, something like
> 
> # Check fullpath tool
> define filecheck # fullpath
> $(if $(wildcard $1),$1,$(error "ERROR: File does not exist: $1"))
> endef
> 
> # Check tools
> ifdef CROSS_COMPILE_ARCH
>   ifdef ALT_COMPILER_PATH
>     CC      := $(call filecheck,$(ALT_COMPILER_PATH)/gcc)
>     CPP    := $(call filecheck,$(ALT_COMPILER_PATH)/g++)
>     NM     := $(call filecheck,$(ALT_COMPILER_PATH)/nm)
>     STRIP := $(call filecheck,$(ALT_COMPILER_PATH)/strip)
>   endif
> endif
> 
> -----
> We also need to make sure we document this in the README-builds.html 
> file, but that can be
> done some other time since it is in a different repository..
> 
> -kto
> 

From Dmitry.Samersoff at oracle.com  Wed Dec  8 06:32:36 2010
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 08 Dec 2010 17:32:36 +0300
Subject: Request for review (S):  6989076
Message-ID: <4CFF9704.80905@oracle.com>

6989076: JVM crashes in klassItable::initialize_itable_for_interface

hotspot should check protection attribute besides the name and signature 
of the method to make a proper  decision wether the method already 
implemented by one of supers or not  when constructing vtable.

http://cr.openjdk.java.net/~dsamersoff/6989076/webrev.01/

-- 
Dmitry Samersoff
J2SE Sustaining team, SPB04
* Give Rabbit time and he'll always get the answer ...

From kevin.walls at sun.com  Wed Dec  8 08:59:47 2010
From: kevin.walls at sun.com (kevin.walls at sun.com)
Date: Wed, 08 Dec 2010 16:59:47 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7003789: PTRACE_GETREGS problems with SA
	on Linux.
Message-ID: <20101208165949.04190471F6@hg.openjdk.java.net>

Changeset: 401fbd7ff77c
Author:    kevinw
Date:      2010-12-08 04:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/401fbd7ff77c

7003789: PTRACE_GETREGS problems with SA on Linux.
Summary: ifdef definitions for PTRACE_GETREGS_REQ clarified
Reviewed-by: dholmes

! agent/src/os/linux/ps_proc.c


From keith.mcguigan at oracle.com  Thu Dec  9 06:26:54 2010
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Thu, 9 Dec 2010 09:26:54 -0500
Subject: request for review: 7004582: Add GetLocalInstance() function to JVMTI
	1.2 
Message-ID: <97B2D6DC-D6AA-4FED-A880-2E614C91AB37@oracle.com>


Hello,

Would appreciate a review for adding this new JVMTI function which  
will be used to enhance JDI event instance filtering.  See the JVMTI  
spec (included in the webrev) for the details.

http://cr.openjdk.java.net/~kamg/7004582/webrev.00/

Thanks!

--
- Keith

From coleen.phillimore at oracle.com  Thu Dec  9 08:35:17 2010
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 09 Dec 2010 11:35:17 -0500
Subject: Request for review 6988439: Parallel Class Loading test deadlock
	involving MethodData_lock and Pend,ing List Lock
Message-ID: <4D010545.3000703@oracle.com>

Summary: Don't acquire methodData_lock while holding pending list lock

We discussed the alternative of allocating the methodData object from 
permgen before acquiring the MethodData_lock, but were concerned about 
leaking methodData objects in the permgen if another thread beats us to 
the locked region.  When we go to native memory for these objects this 
bug fix will be moot and removed.  This patch is to prevent the various 
hangs we've seen from occurring until then.

open webrev at http://cr.openjdk.java.net/~coleenp/6922246/
bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246

Thanks,
Coleen

From dmitriy.samersoff at oracle.com  Thu Dec  9 09:41:06 2010
From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com)
Date: Thu, 09 Dec 2010 17:41:06 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6989076: JVM crashes in
	klassItable::initialize_itable_for_interface
Message-ID: <20101209174109.F2E9E47243@hg.openjdk.java.net>

Changeset: 642e54d1850a
Author:    dsamersoff
Date:      2010-12-09 17:53 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/642e54d1850a

6989076: JVM crashes in klassItable::initialize_itable_for_interface
Summary: hotspot should check protection attribute besides the name and signature of the method when constructing vtable.
Reviewed-by: dcubed

! src/share/vm/oops/klassVtable.cpp


From tom.rodriguez at oracle.com  Thu Dec  9 11:24:01 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 9 Dec 2010 11:24:01 -0800
Subject: Request for review 6988439: Parallel Class Loading test deadlock
	involving MethodData_lock and Pend, ing List Lock
In-Reply-To: <4D010545.3000703@oracle.com>
References: <4D010545.3000703@oracle.com>
Message-ID: <E610953F-7DF1-4EE1-AA28-99F9E9C7A597@oracle.com>


On Dec 9, 2010, at 8:35 AM, Coleen Phillimore wrote:

> Summary: Don't acquire methodData_lock while holding pending list lock
> 
> We discussed the alternative of allocating the methodData object from permgen before acquiring the MethodData_lock, but were concerned about leaking methodData objects in the permgen if another thread beats us to the locked region.  When we go to native memory for these objects this bug fix will be moot and removed.  This patch is to prevent the various hangs we've seen from occurring until then.

Do any of the caller assume that it if didn't trap that an MDO was created?

tom

> 
> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246
> 
> Thanks,
> Coleen


From tom.rodriguez at oracle.com  Thu Dec  9 11:40:17 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 9 Dec 2010 11:40:17 -0800
Subject: request for review: 7004582: Add GetLocalInstance() function to
	JVMTI 1.2
In-Reply-To: <97B2D6DC-D6AA-4FED-A880-2E614C91AB37@oracle.com>
References: <97B2D6DC-D6AA-4FED-A880-2E614C91AB37@oracle.com>
Message-ID: <F5B32817-F480-4ACC-B9B5-A73A2AFA73A3@oracle.com>

Looks good.

tom

On Dec 9, 2010, at 6:26 AM, Keith McGuigan wrote:

> 
> Hello,
> 
> Would appreciate a review for adding this new JVMTI function which will be used to enhance JDI event instance filtering.  See the JVMTI spec (included in the webrev) for the details.
> 
> http://cr.openjdk.java.net/~kamg/7004582/webrev.00/
> 
> Thanks!
> 
> --
> - Keith


From coleen.phillimore at oracle.com  Thu Dec  9 11:59:06 2010
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 09 Dec 2010 14:59:06 -0500
Subject: Request for review 6988439: Parallel Class Loading test deadlock
	involving MethodData_lock and Pend, ing List Lock
In-Reply-To: <E610953F-7DF1-4EE1-AA28-99F9E9C7A597@oracle.com>
References: <4D010545.3000703@oracle.com>
	<E610953F-7DF1-4EE1-AA28-99F9E9C7A597@oracle.com>
Message-ID: <4D01350A.1070903@oracle.com>



Tom Rodriguez wrote:
> On Dec 9, 2010, at 8:35 AM, Coleen Phillimore wrote:
>
>   
>> Summary: Don't acquire methodData_lock while holding pending list lock
>>
>> We discussed the alternative of allocating the methodData object from permgen before acquiring the MethodData_lock, but were concerned about leaking methodData objects in the permgen if another thread beats us to the locked region.  When we go to native memory for these objects this bug fix will be moot and removed.  This patch is to prevent the various hangs we've seen from occurring until then.
>>     
>
> Do any of the caller assume that it if didn't trap that an MDO was created?
>   
No, they both check for null return and do nothing for that.  The 
callers have always expected that it could return null.  The next time 
the function is called, and if null it'll try to create an MDO again.

Coleen
> tom
>
>   
>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246
>>
>> Thanks,
>> Coleen
>>     
>
>   

From keith.mcguigan at oracle.com  Thu Dec  9 14:50:58 2010
From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com)
Date: Thu, 09 Dec 2010 22:50:58 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7004582: Add GetThisObject() function to
	JVMTI 1.2
Message-ID: <20101209225101.9703F47250@hg.openjdk.java.net>

Changeset: 09b4dd4f152b
Author:    kamg
Date:      2010-12-09 15:04 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/09b4dd4f152b

7004582: Add GetThisObject() function to JVMTI 1.2
Summary: Add 'GetThisObject' function
Reviewed-by: never, coleenp

! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/prims/jvmti.xml
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiImpl.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/vframe_hp.cpp


From David.Holmes at oracle.com  Thu Dec  9 16:07:28 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 10 Dec 2010 10:07:28 +1000
Subject: Request for review 6988439: Parallel Class Loading test deadlock
	involving MethodData_lock and Pend,ing List Lock
In-Reply-To: <4D010545.3000703@oracle.com>
References: <4D010545.3000703@oracle.com>
Message-ID: <4D016F40.3020203@oracle.com>

Hi Coleen,

This will certainly avoid the deadlock, but what affect does it have on 
the functionality if we just ignore this request to profile a method?

Thanks,
David

Coleen Phillimore said the following on 12/10/10 02:35:
> Summary: Don't acquire methodData_lock while holding pending list lock
> 
> We discussed the alternative of allocating the methodData object from 
> permgen before acquiring the MethodData_lock, but were concerned about 
> leaking methodData objects in the permgen if another thread beats us to 
> the locked region.  When we go to native memory for these objects this 
> bug fix will be moot and removed.  This patch is to prevent the various 
> hangs we've seen from occurring until then.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246
> 
> Thanks,
> Coleen

From y.s.ramakrishna at oracle.com  Thu Dec  9 16:30:00 2010
From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna)
Date: Thu, 09 Dec 2010 16:30:00 -0800
Subject: Request for review 6988439: Parallel Class Loading test deadlock
	involving MethodData_lock and Pend,ing List Lock
In-Reply-To: <4D016F40.3020203@oracle.com>
References: <4D010545.3000703@oracle.com> <4D016F40.3020203@oracle.com>
Message-ID: <4D017488.6050609@oracle.com>

That would be (some of) the methods executed by the reference handler thread
only. I suggested a refworkload run, but i suspect the difference will
be a wash (famous last words?).

-- ramki

On 12/9/2010 4:07 PM, David Holmes wrote:
> Hi Coleen,
>
> This will certainly avoid the deadlock, but what affect does it have on the functionality if we just
> ignore this request to profile a method?
>
> Thanks,
> David
>
> Coleen Phillimore said the following on 12/10/10 02:35:
>> Summary: Don't acquire methodData_lock while holding pending list lock
>>
>> We discussed the alternative of allocating the methodData object from permgen before acquiring the
>> MethodData_lock, but were concerned about leaking methodData objects in the permgen if another
>> thread beats us to the locked region. When we go to native memory for these objects this bug fix
>> will be moot and removed. This patch is to prevent the various hangs we've seen from occurring
>> until then.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246
>>
>> Thanks,
>> Coleen


From David.Holmes at oracle.com  Thu Dec  9 16:55:55 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 10 Dec 2010 10:55:55 +1000
Subject: Small Request for review: 7005007 - Refine use of
	ALT_COMPILER_PATH to avoid conflict with JPRT usage
In-Reply-To: <4CFEACBE.9010502@oracle.com>
References: <4CFE19FC.3020001@oracle.com>	<945A053A-71CF-4949-B599-1F63A0698C62@oracle.com>
	<4CFEACBE.9010502@oracle.com>
Message-ID: <4D017A9B.5070703@oracle.com>

David Holmes said the following on 12/08/10 07:53:
> Actually the change is gcc.make is not correct - I should have left it 
> as-is - thanks Bob.

No I retract my retraction - the change is fine as-is and I will commit 
today.

Thanks for the review

David

> Will fix and resubmit.
> 
> Thanks for the review anyway.
> 
> David
> 
> Karen Kinnear said the following on 12/07/10 23:15:
>> David,
>>
>> Looks good. Thanks for doing this.
>>
>> thanks,
>> Karen
>>
>> On Dec 7, 2010, at 6:26 AM, David Holmes wrote:
>>
>>> Simple fix to avoid conflicting use of ALT_COMPILER_PATH.
>>>
>>> http://cr.openjdk.java.net/~dholmes/7005007/
>>>
>>> Tested with JPRT linux builds and doing an internal cross-compile build.
>>>
>>> Thanks,
>>> David Holmes
>>

From tom.rodriguez at oracle.com  Thu Dec  9 18:52:31 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 9 Dec 2010 18:52:31 -0800
Subject: Request for review 6988439: Parallel Class Loading test deadlock
	involving MethodData_lock and Pend, ing List Lock
In-Reply-To: <4D017488.6050609@oracle.com>
References: <4D010545.3000703@oracle.com> <4D016F40.3020203@oracle.com>
	<4D017488.6050609@oracle.com>
Message-ID: <3D7896C3-8483-4DD4-BC2A-D2526ACE52E6@oracle.com>


On Dec 9, 2010, at 4:30 PM, Y. Srinivas Ramakrishna wrote:

> That would be (some of) the methods executed by the reference handler thread
> only. I suggested a refworkload run, but i suspect the difference will
> be a wash (famous last words?).

I think the way it works out is that we will delay profiling of ReferenceHandler.run slightly.  We create MDO on entry and on backedges.  There are two backedges in run, one where the lock is held and one where it isn't, so we should eventually create it.

tom

> 
> -- ramki
> 
> On 12/9/2010 4:07 PM, David Holmes wrote:
>> Hi Coleen,
>> 
>> This will certainly avoid the deadlock, but what affect does it have on the functionality if we just
>> ignore this request to profile a method?
>> 
>> Thanks,
>> David
>> 
>> Coleen Phillimore said the following on 12/10/10 02:35:
>>> Summary: Don't acquire methodData_lock while holding pending list lock
>>> 
>>> We discussed the alternative of allocating the methodData object from permgen before acquiring the
>>> MethodData_lock, but were concerned about leaking methodData objects in the permgen if another
>>> thread beats us to the locked region. When we go to native memory for these objects this bug fix
>>> will be moot and removed. This patch is to prevent the various hangs we've seen from occurring
>>> until then.
>>> 
>>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/
>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246
>>> 
>>> Thanks,
>>> Coleen
> 


From y.s.ramakrishna at oracle.com  Thu Dec  9 21:36:12 2010
From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna)
Date: Thu, 09 Dec 2010 21:36:12 -0800
Subject: Request for review 6988439: Parallel Class Loading test deadlock
	involving MethodData_lock and Pend,ing List Lock
In-Reply-To: <3D7896C3-8483-4DD4-BC2A-D2526ACE52E6@oracle.com>
References: <4D010545.3000703@oracle.com> <4D016F40.3020203@oracle.com>
	<4D017488.6050609@oracle.com>
	<3D7896C3-8483-4DD4-BC2A-D2526ACE52E6@oracle.com>
Message-ID: <4D01BC4C.3080208@oracle.com>

On 12/9/2010 6:52 PM, Tom Rodriguez wrote:
...
>
> I think the way it works out is that we will delay profiling of ReferenceHandler.run slightly.  We create MDO on entry and on backedges.  There are two backedges in run, one where the lock is held and one where it isn't, so we should eventually create it.

Thanks for the explanation, Tom!

-- ramki

From david.holmes at oracle.com  Thu Dec  9 21:51:42 2010
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Fri, 10 Dec 2010 05:51:42 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7005007: Refine use of ALT_COMPILER_PATH
	to avoid conflict with JPRT usage
Message-ID: <20101210055145.E88F947273@hg.openjdk.java.net>

Changeset: a5610f0862fe
Author:    dholmes
Date:      2010-12-09 20:12 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a5610f0862fe

7005007: Refine use of ALT_COMPILER_PATH to avoid conflict with JPRT usage
Summary: Check for CROSS_COMPILE_ARCH being set as an indicator to use ALT_COMPILER_PATH
Reviewed-by: acorn, ohair

! make/linux/makefiles/build_vm_def.sh
! make/linux/makefiles/gcc.make


From john.coomes at oracle.com  Fri Dec 10 02:23:56 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Dec 2010 10:23:56 +0000
Subject: hg: jdk7/hotspot-rt: 7 new changesets
Message-ID: <20101210102356.DD0B747288@hg.openjdk.java.net>

Changeset: b011f9ab61f8
Author:    paulk
Date:      2010-11-17 11:55 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/b011f9ab61f8

6997515: KERNEL=0 in JDK7 build causes loss of lzma compression.
Reviewed-by: billyh, jqzuo

! make/deploy-rules.gmk

Changeset: ba8ec3e1e7f2
Author:    jqzuo
Date:      2010-12-07 19:18 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/ba8ec3e1e7f2

Merge


Changeset: fe71f5684c6a
Author:    igor
Date:      2010-11-16 17:07 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/fe71f5684c6a

Merge


Changeset: 7bf38037c3c9
Author:    jqzuo
Date:      2010-11-17 09:43 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/7bf38037c3c9

Merge


Changeset: 05fbe45da7f7
Author:    igor
Date:      2010-11-30 09:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/05fbe45da7f7

Merge


Changeset: 2c2d4f88637b
Author:    igor
Date:      2010-12-07 16:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/2c2d4f88637b

Merge


Changeset: f1591eed71f6
Author:    katleman
Date:      2010-12-09 21:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/f1591eed71f6

Added tag jdk7-b121 for changeset 2c2d4f88637b

! .hgtags


From john.coomes at oracle.com  Fri Dec 10 02:24:03 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Dec 2010 10:24:03 +0000
Subject: hg: jdk7/hotspot-rt/corba: 3 new changesets
Message-ID: <20101210102407.6759947289@hg.openjdk.java.net>

Changeset: dc903ccc6219
Author:    cl
Date:      2010-11-22 14:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/dc903ccc6219

Added tag jdk7-b119 for changeset 39829414ae31

! .hgtags

Changeset: 2cc9f3299210
Author:    ohair
Date:      2010-12-03 19:43 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/2cc9f3299210

Merge

! .hgtags

Changeset: 1523a060032c
Author:    katleman
Date:      2010-12-09 21:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/1523a060032c

Added tag jdk7-b121 for changeset 2cc9f3299210

! .hgtags


From john.coomes at oracle.com  Fri Dec 10 02:24:14 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Dec 2010 10:24:14 +0000
Subject: hg: jdk7/hotspot-rt/jaxp: 4 new changesets
Message-ID: <20101210102414.3282D4728A@hg.openjdk.java.net>

Changeset: d1cb3e473c32
Author:    ohair
Date:      2010-11-23 10:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/d1cb3e473c32

7002248: Update urls for jaxp and jaxws source downloads
Reviewed-by: darcy

! jaxp.properties

Changeset: 1830ef24edb2
Author:    lana
Date:      2010-11-30 15:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/1830ef24edb2

Merge


Changeset: 63dae40fa19f
Author:    lana
Date:      2010-12-06 20:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/63dae40fa19f

Merge


Changeset: 03ff13d19c8f
Author:    katleman
Date:      2010-12-09 21:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/03ff13d19c8f

Added tag jdk7-b121 for changeset 63dae40fa19f

! .hgtags


From john.coomes at oracle.com  Fri Dec 10 02:24:20 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Dec 2010 10:24:20 +0000
Subject: hg: jdk7/hotspot-rt/jaxws: 4 new changesets
Message-ID: <20101210102420.EDE9C4728B@hg.openjdk.java.net>

Changeset: f258bef45f3b
Author:    ohair
Date:      2010-11-23 10:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/f258bef45f3b

7002248: Update urls for jaxp and jaxws source downloads
Reviewed-by: darcy

! jaxws.properties

Changeset: ca2fa57106b3
Author:    lana
Date:      2010-11-30 15:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/ca2fa57106b3

Merge


Changeset: 0fa950117faa
Author:    lana
Date:      2010-12-06 20:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/0fa950117faa

Merge


Changeset: 17b6c48a3449
Author:    katleman
Date:      2010-12-09 21:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/17b6c48a3449

Added tag jdk7-b121 for changeset 0fa950117faa

! .hgtags


From john.coomes at oracle.com  Fri Dec 10 02:26:53 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 10 Dec 2010 10:26:53 +0000
Subject: hg: jdk7/hotspot-rt/jdk: 81 new changesets
Message-ID: <20101210105045.C8BBF4728F@hg.openjdk.java.net>

Changeset: 320c5f5906a1
Author:    cl
Date:      2010-11-22 14:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/320c5f5906a1

Added tag jdk7-b119 for changeset ecab7eefb8f2

! .hgtags

Changeset: c80287e4d606
Author:    ohair
Date:      2010-12-03 19:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c80287e4d606

Merge

! .hgtags

Changeset: 23a6ba383fd7
Author:    jgodinez
Date:      2010-11-18 14:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/23a6ba383fd7

6689925: Add transform attributes to the rendering tests in J2DBench
Reviewed-by: flar, prr

! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java
! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java

Changeset: f81c37805b5b
Author:    lana
Date:      2010-11-30 14:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f81c37805b5b

Merge


Changeset: 07c1c59df4ef
Author:    dav
Date:      2010-11-18 14:26 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/07c1c59df4ef

6990904: (dav) on oel5.5, Frame doesn't show if the Frame has only a MenuBar as its component.
Reviewed-by: dcherepanov, art

! src/solaris/classes/sun/awt/X11/XFramePeer.java
+ test/java/awt/MenuBar/DeadlockTest1/DeadlockTest1.java

Changeset: 9af8c8d2b2e7
Author:    art
Date:      2010-11-25 13:23 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9af8c8d2b2e7

6993784: Clarification to shaped/translucent windows specification is required
Reviewed-by: anthony, dcherepanov

! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/Frame.java
! src/share/classes/java/awt/Window.java

Changeset: dd603732f1cf
Author:    dav
Date:      2010-11-25 15:39 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/dd603732f1cf

6551412: [OpenJDK] Change the 'name=' entry in src/windows/resource/java.manifest XML file.
Reviewed-by: ohair

! src/windows/resource/java.manifest

Changeset: 6c4e7fe53c36
Author:    dcherepanov
Date:      2010-11-26 11:27 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6c4e7fe53c36

6561353: The text for J2SE NervousText demo should be updated to 7.0
Reviewed-by: art

! src/share/demo/applets/NervousText/example1.html

Changeset: b6d79a32b07a
Author:    dcherepanov
Date:      2010-11-26 14:36 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b6d79a32b07a

6699851: setMaximizedbounds not working properly on dual screen environment
Reviewed-by: art, anthony

! src/share/classes/java/awt/Frame.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/windows/classes/sun/awt/windows/WFramePeer.java

Changeset: 3a2355dcef13
Author:    dcherepanov
Date:      2010-11-26 15:07 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3a2355dcef13

6770017: PIT : java/awt/Choice/BlockedWin32Choice/BlockedWin32Choice.java fails on 6u12 b01 pit build
Reviewed-by: art

! src/windows/native/sun/windows/awt_Choice.cpp
! src/windows/native/sun/windows/awt_Choice.h

Changeset: 31196f8ec2d9
Author:    anthony
Date:      2010-11-26 15:41 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/31196f8ec2d9

7002856: Provide an accessor for Container.validateUnconditionally()
Summary: Introduce sun.awt.AWTAccessor.getContainerAccessor().validateUnconditionally()
Reviewed-by: art

! src/share/classes/java/awt/Container.java
! src/share/classes/sun/awt/AWTAccessor.java

Changeset: 7ed7eb6d6ba7
Author:    dcherepanov
Date:      2010-11-26 15:52 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7ed7eb6d6ba7

6953894: docs build reports warning in java.awt.FileDialog
Reviewed-by: art

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

Changeset: 4becb3dd7861
Author:    anthony
Date:      2010-11-30 17:36 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4becb3dd7861

6998592: FileDialog tests crashed on solaris
Summary: Override GtkFileDialogPeer.toFront()
Reviewed-by: art, dcherepanov

! make/sun/xawt/mapfile-vers
! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c
! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.h

Changeset: 357ecafd727b
Author:    dav
Date:      2010-11-30 21:54 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/357ecafd727b

6783910: (dav) java.awt.Color.brighter()/darker() methods make color opaque
Reviewed-by: art, yan

! src/share/classes/java/awt/Color.java
+ test/java/awt/Color/OpacityChange/OpacityChange.java

Changeset: 5fc778c913e7
Author:    lana
Date:      2010-11-30 14:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5fc778c913e7

Merge


Changeset: 452c4c1cc747
Author:    vikram
Date:      2010-11-15 21:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/452c4c1cc747

6939261: Since 1.6.0_18 JMenus at JMenuBar are not selectable by their Mnemonic key anymore
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java

Changeset: 3207aa4438fc
Author:    peytoia
Date:      2010-11-17 01:02 +0900
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3207aa4438fc

6959267: Support Unicode 6.0.0
Reviewed-by: okutsu

! make/tools/GenerateCharacter/CharacterData00.java.template
! make/tools/GenerateCharacter/CharacterData01.java.template
! make/tools/UnicodeData/Scripts.txt
! make/tools/UnicodeData/SpecialCasing.txt
! make/tools/UnicodeData/UnicodeData.txt
! make/tools/UnicodeData/VERSION
! src/share/classes/java/awt/font/NumericShaper.java
! src/share/classes/java/lang/Character.java
! src/share/classes/sun/text/normalizer/NormalizerImpl.java
! src/share/classes/sun/text/resources/ubidi.icu
! src/share/classes/sun/text/resources/unorm.icu
! src/share/classes/sun/text/resources/uprops.icu
! test/java/awt/font/NumericShaper/ShapingTest.java
! test/java/lang/Character/CheckScript.java
! test/java/lang/Character/Scripts.txt

Changeset: a1c87d76d322
Author:    naoto
Date:      2010-11-16 10:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a1c87d76d322

6997999: Remove duplicated entries from ISO language/country code tables
Reviewed-by: okutsu

! src/solaris/native/java/lang/java_props_md.c
! src/solaris/native/java/lang/locale_str.h
! test/java/util/Locale/data/deflocale.rhel5
! test/java/util/Locale/data/deflocale.rhel5.fmtasdefault

Changeset: e6932dbf30d8
Author:    malenkov
Date:      2010-11-17 22:17 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e6932dbf30d8

6447751: Bean Customizer should be detectable by reflection name alone
Reviewed-by: peterz

! src/share/classes/java/beans/Introspector.java
+ test/java/beans/Introspector/Test6447751.java

Changeset: 4222206d85e8
Author:    alexp
Date:      2010-11-18 13:53 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4222206d85e8

6994419: JLayer.removeAll() behavior doesn't correspond to JLayer.remove() behavior.
Reviewed-by: rupashka

! src/share/classes/javax/swing/JLayer.java
+ test/javax/swing/JLayer/6994419/bug6994419.java

Changeset: 10965b60a13e
Author:    alexp
Date:      2010-11-18 19:52 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/10965b60a13e

6997170: Spec for javax.swing.plaf.LayerUI.installUI/uninstallUI() methods contradict behavior of the RI
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/LayerUI.java

Changeset: ef4db681a1fd
Author:    naoto
Date:      2010-11-18 11:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ef4db681a1fd

7000136: Backward compatibility problem in LocaleNameProvider
Reviewed-by: srl
Contributed-by: y.umaoka at gmail.com

! src/share/classes/java/util/spi/LocaleNameProvider.java

Changeset: 917aca396b10
Author:    naoto
Date:      2010-11-23 13:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/917aca396b10

6930106: Testcases with legal notice problems
Reviewed-by: ohair

! test/java/util/ResourceBundle/Bug4168625Test.java

Changeset: 13bbabfee6d4
Author:    peytoia
Date:      2010-11-24 14:13 +0900
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/13bbabfee6d4

7002398: Apply Corrigendum #8 for Unicode 6.0.0
Reviewed-by: okutsu

! make/tools/UnicodeData/UnicodeData.txt
! src/share/classes/sun/text/resources/ubidi.icu
! src/share/classes/sun/text/resources/uprops.icu
+ test/java/text/Bidi/Bug7002398.java

Changeset: f5708f506523
Author:    naoto
Date:      2010-11-24 15:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f5708f506523

6807534: CurrencyNameProvider.getDisplayName(String, Locale) doesn't throw IllegalArgumentException
Reviewed-by: okutsu

! src/share/classes/java/util/spi/CurrencyNameProvider.java
+ test/java/util/Currency/Bug6807534.java

Changeset: 9461aeec7d9c
Author:    amenkov
Date:      2010-11-25 15:58 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9461aeec7d9c

6999872: java.awt.Window instantiation leads to JVM CRASH on Windows, JDK7b118+ fastdebug
Reviewed-by: igor, dcherepanov

! src/windows/bin/java_md.c
! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp
! src/windows/native/sun/windows/awt_Toolkit.cpp
! src/windows/native/sun/windows/awt_Toolkit.h

Changeset: 5ae935cdc84d
Author:    alexp
Date:      2010-11-25 20:23 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5ae935cdc84d

6992847: javax/swing/JLayer/SerializationTest/SerializationTest.java failed in jdk7 just against b114
Reviewed-by: rupashka

! test/javax/swing/JLayer/SerializationTest/SerializationTest.java

Changeset: 98318c740242
Author:    alexp
Date:      2010-11-25 20:25 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/98318c740242

7002176: JLayer docs build produces warnings
Reviewed-by: dav

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

Changeset: 3104dfd74072
Author:    alexp
Date:      2010-11-29 16:01 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3104dfd74072

6559589: Memory leak in JScrollPane.updateUI()
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java
+ test/javax/swing/JScrollPane/6559589/bug6559589.java

Changeset: 54fc4039ddc8
Author:    alexp
Date:      2010-11-29 16:03 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/54fc4039ddc8

6939001: Nimbus: JTabbedPane setBackgroundAt and setForegroundAt have no effect
Reviewed-by: rupashka

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

Changeset: 562d25d284e9
Author:    alexp
Date:      2010-11-29 16:11 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/562d25d284e9

6939227: Nimbus: 6597895 for JCheckBox, JButton and JToggleButton JCK tests
Reviewed-by: rupashka

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

Changeset: 602dfe45c227
Author:    malenkov
Date:      2010-11-29 20:38 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/602dfe45c227

6999033: Methods BorderFactory.createSoftBevelBorder() don't return SoftBevelBorder instances
Reviewed-by: alexp

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

Changeset: 3d92a0fbf5cb
Author:    malenkov
Date:      2010-11-29 21:20 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3d92a0fbf5cb

6981576: TitledBorder.getBorder() returns null in java build 1.7.0-ea-b107
Reviewed-by: alexp

! src/share/classes/javax/swing/border/TitledBorder.java
+ test/javax/swing/border/Test6981576.java

Changeset: 7890dd8535f8
Author:    lana
Date:      2010-11-29 10:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7890dd8535f8

Merge

- src/share/classes/sun/security/krb5/KrbKdcReq.java
- src/share/classes/sun/security/krb5/internal/TCPClient.java
- src/share/classes/sun/security/krb5/internal/UDPClient.java
- src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java

Changeset: d9e3d4f54bad
Author:    rupashka
Date:      2010-11-30 10:35 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d9e3d4f54bad

6988188: The test failed due to Applet thread threw exception
Reviewed-by: alexp

+ test/javax/swing/JFileChooser/4150029/bug4150029.html
+ test/javax/swing/JFileChooser/4150029/bug4150029.java

Changeset: 88308d3affa0
Author:    lana
Date:      2010-11-30 14:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/88308d3affa0

Merge


Changeset: 9ec7802cc759
Author:    alanb
Date:      2010-11-16 15:23 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9ec7802cc759

6613829: (docs) Readable.read() ReadOnlyBufferException is not linked
Reviewed-by: chegar, lancea

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

Changeset: 86ea594c1d10
Author:    valeriep
Date:      2010-11-15 14:32 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/86ea594c1d10

6848930: JSN security test jce/Global/Cipher/PKCS5Padding cannot thrown expected BadPaddingException
Summary: Disabled CKM_DES_CBC_PAD, CKM_DES3_CBC_PAD, CKM_AES_CBC_PAD mechs by default and use our own internal padding impl.
Reviewed-by: wetmore

! src/share/lib/security/sunpkcs11-solaris.cfg

Changeset: cb10e1177801
Author:    valeriep
Date:      2010-11-15 14:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cb10e1177801

6687725: Internal PKCS5Padding impl should throw IllegalBlockSizeException and not BadPaddingException
Summary: Changed to throw IllegalBlockSizeException when the data length isn't multiples of block size
Reviewed-by: wetmore

! src/share/classes/sun/security/pkcs11/P11Cipher.java
+ test/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java

Changeset: 8134c0b75da5
Author:    valeriep
Date:      2010-11-16 11:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8134c0b75da5

Merge


Changeset: f9dbb7d2e8a3
Author:    michaelm
Date:      2010-11-17 14:29 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f9dbb7d2e8a3

6725892: Http server stability issues
Reviewed-by: chegar

! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java
! src/share/classes/com/sun/net/httpserver/HttpsParameters.java
! src/share/classes/sun/net/httpserver/ChunkedInputStream.java
! src/share/classes/sun/net/httpserver/Event.java
! src/share/classes/sun/net/httpserver/ExchangeImpl.java
! src/share/classes/sun/net/httpserver/FixedLengthInputStream.java
! src/share/classes/sun/net/httpserver/HttpConnection.java
! src/share/classes/sun/net/httpserver/Request.java
! src/share/classes/sun/net/httpserver/SSLStreams.java
- src/share/classes/sun/net/httpserver/SelectorCache.java
! src/share/classes/sun/net/httpserver/ServerConfig.java
! src/share/classes/sun/net/httpserver/ServerImpl.java
! test/com/sun/net/httpserver/Test.java
! test/com/sun/net/httpserver/Test1.java
! test/com/sun/net/httpserver/Test13.java
+ test/com/sun/net/httpserver/bugs/6725892/Test.java
! test/com/sun/net/httpserver/bugs/B6401598.java

Changeset: 664b35adabd2
Author:    michaelm
Date:      2010-11-17 14:32 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/664b35adabd2

Merge


Changeset: 59d10b97be7c
Author:    sherman
Date:      2010-11-17 15:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/59d10b97be7c

6615506: (fmt spec) Date/Time conversion table missing column for 'Z'
Summary: added the column entry back in
Reviewed-by: alanb

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

Changeset: ce757906302f
Author:    sherman
Date:      2010-11-17 21:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ce757906302f

6217210: RFE: Support for Cp833 in 1.4.2
Summary: Forward port the Cp833 charset
Reviewed-by: poonam

! make/sun/nio/cs/FILES_java.gmk
+ make/tools/CharsetMapping/IBM833.c2b
+ make/tools/CharsetMapping/IBM833.map
! make/tools/CharsetMapping/extsbcs
+ src/share/classes/sun/io/ByteToCharCp833.java
+ src/share/classes/sun/io/CharToByteCp833.java
! src/share/classes/sun/io/CharacterEncoding.java
! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java
! test/sun/nio/cs/CheckHistoricalNames.java

Changeset: 2e0204644cf4
Author:    alanb
Date:      2010-11-18 19:16 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2e0204644cf4

7000913: (bf) CharBuffer.wrap, slice, position, slice leads to CharBuffer with incorrect offser
Reviewed-by: forax

! src/share/classes/java/nio/StringCharBuffer.java
! test/java/nio/Buffer/StringCharBufferSliceTest.java

Changeset: fbd3395f973b
Author:    alanb
Date:      2010-11-18 19:17 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fbd3395f973b

Merge

- src/share/classes/sun/net/httpserver/SelectorCache.java

Changeset: d5489d652f6f
Author:    dl
Date:      2010-11-19 10:43 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d5489d652f6f

6712185: java/util/concurrent/Executors/AutoShutdown.java fails on slow or busy systems
Reviewed-by: chegar, alanb

! test/ProblemList.txt
! test/java/util/concurrent/Executors/AutoShutdown.java

Changeset: 3092c842b0ea
Author:    michaelm
Date:      2010-11-19 13:30 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3092c842b0ea

7001301: com/sun/net/httpserver/bugs/6725892/Test.java failing
Reviewed-by: alanb

! test/com/sun/net/httpserver/bugs/6725892/Test.java

Changeset: 892c54251ac8
Author:    michaelm
Date:      2010-11-19 13:35 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/892c54251ac8

Merge


Changeset: f30e1e1a4d90
Author:    mchung
Date:      2010-11-19 10:00 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f30e1e1a4d90

6631046: BufferedInputStream.available() reports negative int on very large inputstream
Reviewed-by: dholmes, alanb, mduigou

! src/share/classes/java/io/BufferedInputStream.java
! src/share/classes/java/io/PushbackInputStream.java

Changeset: d9e4556acd4a
Author:    sherman
Date:      2010-11-19 12:55 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d9e4556acd4a

6989471: compiler warnings building java/zip native code
Summary: remvoed the warning
Reviewed-by: ohair, alanb

! src/share/native/java/util/zip/zip_util.c
! src/share/native/java/util/zip/zlib-1.2.3/compress.c
! src/share/native/java/util/zip/zlib-1.2.3/uncompr.c

Changeset: b44704ce8a08
Author:    sherman
Date:      2010-11-19 12:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b44704ce8a08

6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3
Summary: changged utf-8's CharsetEncoder.maxBytesPerChar to 3
Reviewed-by: alanb

! src/share/classes/sun/nio/cs/UTF_8.java

Changeset: ff619988afac
Author:    lancea
Date:      2010-11-19 17:15 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ff619988afac

7000752: Duplicate entry in RowSetResourceBundles.properties
Reviewed-by: alanb

! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties
! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java

Changeset: bf407ff3e97b
Author:    lancea
Date:      2010-11-19 17:18 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/bf407ff3e97b

7001669: Typo in javadocs for SQLPermission
Reviewed-by: alanb

! src/share/classes/java/sql/SQLPermission.java

Changeset: 6deeca9378c0
Author:    valeriep
Date:      2010-11-19 16:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6deeca9378c0

6203816: Can not run test/java/security/Security/ClassLoaderDeadlock.sh from the command line
Summary: Fixed the script to not delete the provider sub-directory
Reviewed-by: weijun

! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh

Changeset: 784f2f094051
Author:    valeriep
Date:      2010-11-19 17:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/784f2f094051

6720456: New 4150 may have larger blowfish keysizes
Summary: Changed to use TBD value instead of FAIL
Reviewed-by: weijun

! test/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java

Changeset: b66c09b7ce85
Author:    xuelei
Date:      2010-11-20 07:00 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b66c09b7ce85

6903584: Legal notice repair: Three files under jdk/src/share/classes/sun/security/ssl/
Reviewed-by: weijun

! src/share/classes/sun/security/ssl/Krb5Helper.java
! src/share/classes/sun/security/ssl/Krb5Proxy.java
! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java

Changeset: c1734c00a8ba
Author:    weijun
Date:      2010-11-22 09:43 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c1734c00a8ba

6979329: CCacheInputStream fails to read ticket cache files from Kerberos 1.8.1
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java
! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
+ test/sun/security/krb5/UnknownCCEntry.java

Changeset: 4bb2a0229796
Author:    michaelm
Date:      2010-11-22 16:09 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4bb2a0229796

6984182: Setting SO_RCVBUF/SO_SNDBUF to larger than tcp_max_buf fails on Solaris 11 if kernel params changed
Reviewed-by: alanb, chegar

! src/solaris/native/java/net/net_util_md.c

Changeset: 4b93d39eb352
Author:    michaelm
Date:      2010-11-22 16:11 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4b93d39eb352

Merge


Changeset: 951db417fc3c
Author:    mullan
Date:      2010-11-22 10:16 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/951db417fc3c

6995424: Eliminate dependency to a deprecated API com.sun.security.auth.PolicyFile
Reviewed-by: mchung

! src/share/classes/javax/security/auth/Policy.java
! src/share/classes/javax/security/auth/SubjectDomainCombiner.java

Changeset: 83d08a3e4e04
Author:    mullan
Date:      2010-11-22 10:18 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/83d08a3e4e04

Merge

- src/share/classes/sun/net/httpserver/SelectorCache.java

Changeset: 8aa383f37420
Author:    mullan
Date:      2010-11-22 11:27 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8aa383f37420

Merge


Changeset: 0049b9a85e74
Author:    sherman
Date:      2010-11-22 16:03 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0049b9a85e74

6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length
Summary: don't throw OOME when in or out buffer size is 0 length
Reviewed-by: alanb

! src/share/native/java/util/zip/Deflater.c
! src/share/native/java/util/zip/Inflater.c

Changeset: 7fac77daa9be
Author:    sherman
Date:      2010-11-22 16:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7fac77daa9be

7001434: charset name for Cp833 should be x-IBM833.
Summary: changed the name to x-IBM833 in extsbcs
Reviewed-by: alanb

! make/tools/CharsetMapping/extsbcs

Changeset: de402590e18f
Author:    weijun
Date:      2010-11-24 07:43 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/de402590e18f

7002036: ktab return code changes on a error case
Reviewed-by: valeriep

! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java
+ test/sun/security/krb5/tools/ktarg.sh

Changeset: 32f3094b2c73
Author:    ksrini
Date:      2010-11-23 16:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/32f3094b2c73

6452854: Provide a flag to print the java configuration
Reviewed-by: darcy, mchung, sherman, dholmes, mduigou

! src/share/bin/java.c
! src/share/classes/sun/launcher/LauncherHelper.java
! src/share/classes/sun/launcher/resources/launcher.properties
+ test/tools/launcher/Settings.java

Changeset: 4d9e09600175
Author:    alanb
Date:      2010-11-24 09:51 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4d9e09600175

6878369: (ch) AsynchronousSocketChannel read/write methods that specify timeouts should not throw IAE
Reviewed-by: forax

! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java
! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java
! test/java/nio/channels/AsynchronousSocketChannel/Basic.java

Changeset: 6a8d669d963a
Author:    ksrini
Date:      2010-11-27 07:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6a8d669d963a

7002986: (pack200) intermittent failures compiling pack200
Reviewed-by: jjg

! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java
! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java
! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java
! src/share/classes/com/sun/java/util/jar/pack/Code.java
! src/share/classes/com/sun/java/util/jar/pack/Coding.java
! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java
! src/share/classes/com/sun/java/util/jar/pack/CodingMethod.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Constants.java
! src/share/classes/com/sun/java/util/jar/pack/Driver.java
! src/share/classes/com/sun/java/util/jar/pack/Fixups.java
! src/share/classes/com/sun/java/util/jar/pack/Histogram.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/Package.java
! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java
! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java
! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/Utils.java

Changeset: 58fa22ee49f9
Author:    mduigou
Date:      2010-11-29 10:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/58fa22ee49f9

6998016: Incorrect ifdef nesting in sane-gcc-compiler rule
6998014: Use /etc/lsb-release, when available, to detect linux variant and version
Reviewed-by: dholmes, ohair

! make/common/shared/Defs-linux.gmk
! make/common/shared/Sanity.gmk

Changeset: d05cb7c442b2
Author:    mduigou
Date:      2010-11-29 10:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d05cb7c442b2

Merge


Changeset: 714eb2807ed8
Author:    mduigou
Date:      2010-11-30 13:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/714eb2807ed8

7003544: backout of openjdk changeset 58fa22ee49f9
Reviewed-by: ohair

! make/common/shared/Defs-linux.gmk
! make/common/shared/Sanity.gmk

Changeset: b9745d2b6595
Author:    mduigou
Date:      2010-11-30 13:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b9745d2b6595

Merge


Changeset: b868e7e73a25
Author:    lana
Date:      2010-11-30 15:07 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b868e7e73a25

Merge

- src/share/classes/sun/net/httpserver/SelectorCache.java

Changeset: c65ab22137f8
Author:    lana
Date:      2010-12-06 20:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c65ab22137f8

Merge

- src/share/classes/sun/net/httpserver/SelectorCache.java

Changeset: 720863527b90
Author:    herrick
Date:      2010-10-22 14:14 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/720863527b90

Merge


Changeset: 1a6bcdf42058
Author:    igor
Date:      2010-11-18 10:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1a6bcdf42058

Merge

- src/share/classes/java/dyn/JavaMethodHandle.java
- src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java
- src/share/classes/sun/java2d/pisces/LineSink.java
- src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java
- test/java/nio/channels/AsynchronousDatagramChannel/Basic.java

Changeset: f32734df1bdd
Author:    ccheung
Date:      2010-11-09 23:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f32734df1bdd

6992226: Missing windows COMPANY file property settings
Reviewed-by: ohair

! make/common/Defs.gmk

Changeset: 4f33cfb40c39
Author:    igor
Date:      2010-11-30 09:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4f33cfb40c39

Merge

- src/share/classes/sun/security/krb5/KrbKdcReq.java
- src/share/classes/sun/security/krb5/internal/TCPClient.java
- src/share/classes/sun/security/krb5/internal/UDPClient.java
- src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java

Changeset: a661d8587b5d
Author:    igor
Date:      2010-12-08 00:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a661d8587b5d

Merge

- src/share/classes/sun/net/httpserver/SelectorCache.java

Changeset: ac311eb325bf
Author:    katleman
Date:      2010-12-09 21:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ac311eb325bf

Added tag jdk7-b121 for changeset a661d8587b5d

! .hgtags


From coleen.phillimore at oracle.com  Fri Dec 10 13:47:31 2010
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 10 Dec 2010 21:47:31 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6988439: Parallel Class Loading test
	deadlock involving MethodData_lock and Pending List Lock
Message-ID: <20101210214733.DF430472B1@hg.openjdk.java.net>

Changeset: 7cf1a74771e8
Author:    coleenp
Date:      2010-12-10 12:13 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7cf1a74771e8

6988439: Parallel Class Loading test deadlock involving MethodData_lock and Pending List Lock
Summary: Don't acquire methodData_lock while holding pending list lock
Reviewed-by: kvn, never, ysr

! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/instanceRefKlass.hpp
! src/share/vm/oops/methodOop.cpp


From zhengyu.gu at oracle.com  Sat Dec 11 13:03:26 2010
From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com)
Date: Sat, 11 Dec 2010 21:03:26 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20101211210331.A2AF3472EA@hg.openjdk.java.net>

Changeset: 2d4762ec74af
Author:    zgu
Date:      2010-12-11 13:20 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2d4762ec74af

7003748: Decode C stack frames when symbols are presented (PhoneHome project)
Summary: Implemented in-process C native stack frame decoding when symbols are available.
Reviewed-by: coleenp, never

! make/solaris/makefiles/vm.make
+ src/os/linux/vm/decoder_linux.cpp
! src/os/linux/vm/os_linux.cpp
+ src/os/solaris/vm/decoder_solaris.cpp
! src/os/solaris/vm/os_solaris.cpp
+ src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/frame.cpp
+ src/share/vm/utilities/decoder.cpp
+ src/share/vm/utilities/decoder.hpp
+ src/share/vm/utilities/elfFile.cpp
+ src/share/vm/utilities/elfFile.hpp
+ src/share/vm/utilities/elfStringTable.cpp
+ src/share/vm/utilities/elfStringTable.hpp
+ src/share/vm/utilities/elfSymbolTable.cpp
+ src/share/vm/utilities/elfSymbolTable.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 54f5dd2aa1d9
Author:    zgu
Date:      2010-12-11 13:46 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/54f5dd2aa1d9

Merge

! make/solaris/makefiles/vm.make
- src/os/linux/launcher/java.c
- src/os/linux/launcher/java.h
- src/os/linux/launcher/java_md.c
- src/os/linux/launcher/java_md.h
- src/os/linux/vm/hpi_linux.cpp
- src/os/linux/vm/hpi_linux.hpp
! src/os/linux/vm/os_linux.cpp
- src/os/solaris/launcher/java.c
- src/os/solaris/launcher/java.h
- src/os/solaris/launcher/java_md.c
- src/os/solaris/launcher/java_md.h
- src/os/solaris/vm/hpi_solaris.cpp
- src/os/solaris/vm/hpi_solaris.hpp
! src/os/solaris/vm/os_solaris.cpp
- src/os/windows/vm/hpi_windows.cpp
- src/os/windows/vm/hpi_windows.hpp
! src/os/windows/vm/os_windows.cpp
- src/share/vm/prims/hpi_imported.h
! src/share/vm/runtime/frame.cpp
- src/share/vm/runtime/hpi.cpp
- src/share/vm/runtime/hpi.hpp


From coleen.phillimore at oracle.com  Mon Dec 13 16:44:52 2010
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 14 Dec 2010 00:44:52 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 17 new changesets
Message-ID: <20101214004522.2A17947374@hg.openjdk.java.net>

Changeset: 016a3628c885
Author:    tonyp
Date:      2010-12-07 16:47 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/016a3628c885

6994056: G1: when GC locker is active, extend the Eden instead of allocating into the old gen
Summary: Allow the eden to the expanded up to a point when the GC locker is active.
Reviewed-by: jwilhelm, johnc, ysr, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 3cd116fd11be
Author:    johnc
Date:      2010-12-07 16:18 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3cd116fd11be

6994628: G1: Test gc/gctests/FinalizeTest05 fails (one live object is finalized)
Summary: The Solaris Studio 12 update 1 C++ compiler was incorrectly re-ordering the reads of an object's mark word in oopDesc::forward_to_atomic(). This opened a small window where one thread could execute the successful CAS path even though another thread had already successfully forwarded the object. This could result in an object being copied twice. The code in oopDesc::forward_to_atomic() was changed to read the mark word once.
Reviewed-by: ysr, tonyp

! src/share/vm/oops/oop.pcgc.inline.hpp

Changeset: 459fad165e5e
Author:    johnc
Date:      2010-12-07 16:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/459fad165e5e

Merge


Changeset: 6cd6d394f280
Author:    ysr
Date:      2010-12-07 21:55 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6cd6d394f280

7001033: assert(gch->gc_cause() == GCCause::_scavenge_alot || !gch->incremental_collection_failed())
7002546: regression on SpecJbb2005 on 7b118 comparing to 7b117 on small heaps
Summary: Relaxed assertion checking related to incremental_collection_failed flag to allow for ExplicitGCInvokesConcurrent behaviour where we do not want a failing scavenge to bail to a stop-world collection. Parameterized incremental_collection_will_fail() so we can selectively use, or not use, as appropriate, the statistical prediction at specific use sites. This essentially reverts the scavenge bail-out logic to what it was prior to some recent changes that had inadvertently started using the statistical prediction which can be noisy in the presence of bursty loads. Added some associated verbose non-product debugging messages.
Reviewed-by: johnc, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp

Changeset: 8df09fb45352
Author:    ysr
Date:      2010-12-09 09:22 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8df09fb45352

7005259: CMS: BubbleUpRef asserts referent(obj)->is_oop() failed: Enqueued a bad referent
Summary: Relaxed the assert by allowing NULL referents when discovery may be concurrent.
Reviewed-by: johnc, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp

Changeset: f0ef5f5a460f
Author:    ysr
Date:      2010-12-09 21:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f0ef5f5a460f

Merge

- src/os/linux/launcher/java.c
- src/os/linux/launcher/java.h
- src/os/linux/launcher/java_md.c
- src/os/linux/launcher/java_md.h
- src/os/linux/vm/hpi_linux.cpp
- src/os/linux/vm/hpi_linux.hpp
- src/os/solaris/launcher/java.c
- src/os/solaris/launcher/java.h
- src/os/solaris/launcher/java_md.c
- src/os/solaris/launcher/java_md.h
- src/os/solaris/vm/hpi_solaris.cpp
- src/os/solaris/vm/hpi_solaris.hpp
- src/os/windows/vm/hpi_windows.cpp
- src/os/windows/vm/hpi_windows.hpp
- src/share/vm/prims/hpi_imported.h
! src/share/vm/runtime/globals.hpp
- src/share/vm/runtime/hpi.cpp
- src/share/vm/runtime/hpi.hpp

Changeset: 79401ff1d56d
Author:    lana
Date:      2010-11-13 18:40 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/79401ff1d56d

Merge

- src/os/linux/vm/objectMonitor_linux.cpp
- src/os/linux/vm/objectMonitor_linux.hpp
- src/os/linux/vm/objectMonitor_linux.inline.hpp
- src/os/solaris/vm/objectMonitor_solaris.cpp
- src/os/solaris/vm/objectMonitor_solaris.hpp
- src/os/solaris/vm/objectMonitor_solaris.inline.hpp
- src/os/windows/vm/objectMonitor_windows.cpp
- src/os/windows/vm/objectMonitor_windows.hpp
- src/os/windows/vm/objectMonitor_windows.inline.hpp

Changeset: f5603a6e5042
Author:    lana
Date:      2010-11-17 22:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f5603a6e5042

Merge


Changeset: 18134a5c6da5
Author:    cl
Date:      2010-12-02 19:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/18134a5c6da5

Added tag jdk7-b120 for changeset f5603a6e5042

! .hgtags

Changeset: 33bfde7da72a
Author:    trims
Date:      2010-12-03 09:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/33bfde7da72a

Added tag hs20-b03 for changeset 5484e7c53fa7

! .hgtags

Changeset: 073378594ec6
Author:    cl
Date:      2010-11-22 14:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/073378594ec6

Added tag jdk7-b119 for changeset 5484e7c53fa7

! .hgtags

Changeset: 3f3653ab7af8
Author:    ohair
Date:      2010-12-03 19:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3f3653ab7af8

Merge

! .hgtags

Changeset: 3a548dc9cb45
Author:    katleman
Date:      2010-12-09 21:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3a548dc9cb45

Added tag jdk7-b121 for changeset 3f3653ab7af8

! .hgtags

Changeset: 058f494c8b6d
Author:    trims
Date:      2010-12-10 15:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/058f494c8b6d

Merge

! .hgtags

Changeset: 505c913f22f8
Author:    trims
Date:      2010-12-10 17:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/505c913f22f8

Merge

- make/linux/makefiles/makedeps.make
- make/solaris/makefiles/makedeps.make
- make/windows/README
- make/windows/makefiles/makedeps.make
- src/os/linux/launcher/java.c
- src/os/linux/launcher/java.h
- src/os/linux/launcher/java_md.c
- src/os/linux/launcher/java_md.h
- src/os/linux/vm/hpi_linux.cpp
- src/os/linux/vm/hpi_linux.hpp
- src/os/solaris/launcher/java.c
- src/os/solaris/launcher/java.h
- src/os/solaris/launcher/java_md.c
- src/os/solaris/launcher/java_md.h
- src/os/solaris/vm/hpi_solaris.cpp
- src/os/solaris/vm/hpi_solaris.hpp
- src/os/windows/vm/hpi_windows.cpp
- src/os/windows/vm/hpi_windows.hpp
- src/share/tools/MakeDeps/ArgsParser.java
- src/share/tools/MakeDeps/BuildConfig.java
- src/share/tools/MakeDeps/Database.java
- src/share/tools/MakeDeps/DirectoryTree.java
- src/share/tools/MakeDeps/DirectoryTreeNode.java
- src/share/tools/MakeDeps/FileFormatException.java
- src/share/tools/MakeDeps/FileList.java
- src/share/tools/MakeDeps/FileName.java
- src/share/tools/MakeDeps/Macro.java
- src/share/tools/MakeDeps/MacroDefinitions.java
- src/share/tools/MakeDeps/MakeDeps.java
- src/share/tools/MakeDeps/MetroWerksMacPlatform.java
- src/share/tools/MakeDeps/Platform.java
- src/share/tools/MakeDeps/UnixPlatform.java
- src/share/tools/MakeDeps/Util.java
- src/share/tools/MakeDeps/WinGammaPlatform.java
- src/share/tools/MakeDeps/WinGammaPlatformVC6.java
- src/share/tools/MakeDeps/WinGammaPlatformVC7.java
- src/share/tools/MakeDeps/WinGammaPlatformVC8.java
- src/share/tools/MakeDeps/WinGammaPlatformVC9.java
- src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
- src/share/vm/gc_implementation/includeDB_gc_g1
- src/share/vm/gc_implementation/includeDB_gc_parNew
- src/share/vm/gc_implementation/includeDB_gc_parallelScavenge
- src/share/vm/gc_implementation/includeDB_gc_serial
- src/share/vm/gc_implementation/includeDB_gc_shared
- src/share/vm/includeDB_compiler1
- src/share/vm/includeDB_compiler2
- src/share/vm/includeDB_core
- src/share/vm/includeDB_features
- src/share/vm/includeDB_gc
- src/share/vm/includeDB_gc_parallel
- src/share/vm/includeDB_jvmti
- src/share/vm/includeDB_shark
- src/share/vm/includeDB_zero
- src/share/vm/prims/hpi_imported.h
- src/share/vm/runtime/hpi.cpp
- src/share/vm/runtime/hpi.hpp

Changeset: 0d4395745860
Author:    trims
Date:      2010-12-10 18:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0d4395745860

7006221: Bump the HS20 build number to 04
Summary: Update the HS20 build number to 04
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 06ba96862949
Author:    coleenp
Date:      2010-12-13 14:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/06ba96862949

Merge



From coleen.phillimore at oracle.com  Tue Dec 14 11:23:09 2010
From: coleen.phillimore at oracle.com (coleen phillimore)
Date: Tue, 14 Dec 2010 14:23:09 -0500
Subject: Request for review: 7006471: fix for 6988439 crashes when pending
	list lock is null
Message-ID: <4D07C41D.8080409@oracle.com>

Summary: missing null check in owns_pending_list_lock() because this can 
be called before pending_list_lock is initialized.

Tested with -XX:CompileThreshold=10 a bunch of mixed tests plus the 
failing test case.

open webrev at http://cr.openjdk.java.net/~coleenp/7006471/
bug link at http://bugs.sun.com/view_bug.do?bug_id=7006471

Thanks,
Coleen

From tom.rodriguez at oracle.com  Tue Dec 14 11:28:58 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Tue, 14 Dec 2010 11:28:58 -0800
Subject: Request for review: 7006471: fix for 6988439 crashes when pending
	list lock is null
In-Reply-To: <4D07C41D.8080409@oracle.com>
References: <4D07C41D.8080409@oracle.com>
Message-ID: <8DA33D6B-50F6-450E-9B3F-7FC2FB873D60@oracle.com>

Looks good.

tom

On Dec 14, 2010, at 11:23 AM, coleen phillimore wrote:

> Summary: missing null check in owns_pending_list_lock() because this can be called before pending_list_lock is initialized.
> 
> Tested with -XX:CompileThreshold=10 a bunch of mixed tests plus the failing test case.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/7006471/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7006471
> 
> Thanks,
> Coleen


From vladimir.kozlov at oracle.com  Tue Dec 14 12:01:53 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 14 Dec 2010 12:01:53 -0800
Subject: Request for review: 7006471: fix for 6988439 crashes when pending
	list lock is null
In-Reply-To: <4D07C41D.8080409@oracle.com>
References: <4D07C41D.8080409@oracle.com>
Message-ID: <4D07CD31.9040608@oracle.com>

Good.

Vladimir

coleen phillimore wrote:
> Summary: missing null check in owns_pending_list_lock() because this can 
> be called before pending_list_lock is initialized.
> 
> Tested with -XX:CompileThreshold=10 a bunch of mixed tests plus the 
> failing test case.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/7006471/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7006471
> 
> Thanks,
> Coleen

From David.Holmes at oracle.com  Tue Dec 14 15:19:45 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 15 Dec 2010 09:19:45 +1000
Subject: Request for review: 7006471: fix for 6988439 crashes when pending
	list lock is null
In-Reply-To: <8DA33D6B-50F6-450E-9B3F-7FC2FB873D60@oracle.com>
References: <4D07C41D.8080409@oracle.com>
	<8DA33D6B-50F6-450E-9B3F-7FC2FB873D60@oracle.com>
Message-ID: <4D07FB91.2040104@oracle.com>

Ditto.

David

Tom Rodriguez said the following on 12/15/10 05:28:
> Looks good.
> 
> tom
> 
> On Dec 14, 2010, at 11:23 AM, coleen phillimore wrote:
> 
>> Summary: missing null check in owns_pending_list_lock() because this can be called before pending_list_lock is initialized.
>>
>> Tested with -XX:CompileThreshold=10 a bunch of mixed tests plus the failing test case.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/7006471/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7006471
>>
>> Thanks,
>> Coleen
> 

From coleen.phillimore at oracle.com  Tue Dec 14 18:59:21 2010
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 15 Dec 2010 02:59:21 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7006471: fix for 6988439 crashes when
	pending list lock is null
Message-ID: <20101215025926.20E51473B1@hg.openjdk.java.net>

Changeset: b03e6b4c7c75
Author:    coleenp
Date:      2010-12-14 15:10 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b03e6b4c7c75

7006471: fix for 6988439 crashes when pending list lock is null
Summary: missing null check in owns_pending_list_lock() because this can be called before pending_list_lock is initialized.
Reviewed-by: never, kvn

! src/share/vm/oops/instanceRefKlass.cpp


From jacklusf at gmail.com  Tue Dec 14 23:07:10 2010
From: jacklusf at gmail.com (Xiaobin Lu)
Date: Tue, 14 Dec 2010 23:07:10 -0800
Subject: Trace object allocation flag proposal
Message-ID: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>

Hi folks,

I would like to propose a way to trace object allocation on Linux. On
Solaris, we have DTrace which is pretty nice. But on Linux, it is almost
impossible to do so. Correct me if I am wrong here.

So I am thinking to add a manageable VM flag and let's call it
TraceObjectAllocation. When enabled, we can output something like:

thread id: 10     class name: java/lang/reflect/Method             size: 80
bytes
thread id: 10     class name: [Ljava/lang/Class;                    size: 16
bytes
thread id: 10     class name: [C
                         size: 56 bytes
thread id: 10     class name: java/lang/reflect/Method            size: 80
bytes
thread id: 10     class name: [Ljava/lang/Class;                   size: 16
bytes

As you could imagine, this could be very useful to keep track of object
allocation behavior in the app. Some smart tool can take advantage of this
to print a histogram (like top 10 hot allocations) of object allocation. I
would like to know your thoughts and suggestions on this.

I have a detailed proposal on this attached in PDF file.

Thanks,

-Xiaobin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101214/419ee86d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Traceobjectallocationondemand.pdf
Type: application/pdf
Size: 274217 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101214/419ee86d/attachment-0001.pdf 

From David.Holmes at oracle.com  Tue Dec 14 23:58:09 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 15 Dec 2010 17:58:09 +1000
Subject: Trace object allocation flag proposal
In-Reply-To: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>
Message-ID: <4D087511.30902@oracle.com>

Hi Xiaobin,

The problem with tracing like this is that to be useful the tracing must 
be unobtrusive and be able to handle getting called millions of times 
(which is what will happen in those GC scenarios you describe). The 
sheer volume of data generated as you suggest below would overwhelm the 
app and be pretty hard to work with.

Per-thread statistics of particular types (or of objects larger than a 
certain size) might be more useful, with a dump able to be requested 
on-demand.

But I think you'd need to be able to combine this with heap dump info to 
be useful.

It really depends on exactly what info you want to be able to deduce: 
simple number of objects of given types, hot allocation sites, hot 
threads, ...

Cheers,
David

Xiaobin Lu said the following on 12/15/10 17:07:
> Hi folks,
> 
> I would like to propose a way to trace object allocation on Linux. On 
> Solaris, we have DTrace which is pretty nice. But on Linux, it is almost 
> impossible to do so. Correct me if I am wrong here.
> 
> So I am thinking to add a manageable VM flag and let's call it 
> TraceObjectAllocation. When enabled, we can output something like:
> 
> thread id: 10     class name: java/lang/reflect/Method             size: 
> 80 bytes
> thread id: 10     class name: [Ljava/lang/Class;                  
>   size: 16 bytes
> thread id: 10     class name: [C                                  
>                          size: 56 bytes
> thread id: 10     class name: java/lang/reflect/Method            size: 
> 80 bytes
> thread id: 10     class name: [Ljava/lang/Class;                   size: 
> 16 bytes
> 
> As you could imagine, this could be very useful to keep track of object 
> allocation behavior in the app. Some smart tool can take advantage of 
> this to print a histogram (like top 10 hot allocations) of object 
> allocation. I would like to know your thoughts and suggestions on this.
> 
> I have a detailed proposal on this attached in PDF file.
> 
> Thanks,
> 
> -Xiaobin
> 
> 

From staffan.larsen at oracle.com  Wed Dec 15 09:56:09 2010
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Wed, 15 Dec 2010 17:56:09 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20101215175615.65EA3473E8@hg.openjdk.java.net>

Changeset: aa6e219afbf1
Author:    sla
Date:      2010-12-15 07:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/aa6e219afbf1

7006354: Updates to Visual Studio project creation and development launcher
Summary: Updates to Visual Studio project creation and development launcher
Reviewed-by: stefank, coleenp

! make/linux/makefiles/buildtree.make
! make/solaris/makefiles/buildtree.make
! make/windows/build_vm_def.sh
! make/windows/create.bat
! make/windows/makefiles/adlc.make
! make/windows/makefiles/compile.make
! make/windows/makefiles/debug.make
! make/windows/makefiles/fastdebug.make
! make/windows/makefiles/generated.make
! make/windows/makefiles/launcher.make
! make/windows/makefiles/product.make
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/rules.make
! make/windows/makefiles/vm.make
! make/windows/projectfiles/common/Makefile
! make/windows/projectfiles/compiler1/Makefile
! make/windows/projectfiles/compiler1/vm.def
! make/windows/projectfiles/compiler2/Makefile
! make/windows/projectfiles/compiler2/vm.def
! make/windows/projectfiles/core/Makefile
! make/windows/projectfiles/core/vm.def
! make/windows/projectfiles/kernel/Makefile
! make/windows/projectfiles/kernel/vm.def
! make/windows/projectfiles/tiered/Makefile
! make/windows/projectfiles/tiered/vm.def
! src/os/posix/launcher/java_md.c
! src/os/posix/launcher/launcher.script
! src/os/windows/launcher/java_md.c
! src/os/windows/vm/os_windows.cpp
! src/share/tools/ProjectCreator/BuildConfig.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC6.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC8.java
! src/share/tools/launcher/java.c
! src/share/tools/launcher/jli_util.c

Changeset: 450ece4d8a10
Author:    sla
Date:      2010-12-15 08:03 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/450ece4d8a10

Merge



From jacklusf at gmail.com  Wed Dec 15 10:00:50 2010
From: jacklusf at gmail.com (Xiaobin Lu)
Date: Wed, 15 Dec 2010 10:00:50 -0800
Subject: Trace object allocation flag proposal
In-Reply-To: <4D087511.30902@oracle.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>
	<4D087511.30902@oracle.com>
Message-ID: <AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>

Thanks for your feedback, David.

Let me try to clarify with some more background information.

One of the problems many application has is the object allocation problem
(Duh ...). Over releases, GC becomes more and more frequent. It is pretty
hard for one single team to find out where the problem goes wrong. The
existing tool such as jhat or jmap is very hard to work with giant heap dump
file. So the flag I propose is mostly for diagnostic purpose, it won't be
enabled by default in production. Having said so, if we make it as a
manageable flag, we can turn it on when GC goes wild.

Another value this flag could provide is to find out why sometime OOM
occurs. For example, someone who wrote a search application on top of Lucene
framework suddenly found a crash due to OOM. The stack trace points to
Lucene code which is hard to instrument, so this flag could provide insight
to why the allocation fails. Maybe it is due to a corrupted length value
passed to "new byte[length];" etc.

I like your idea on per-thread basis, however, for a lot of web application,
thread comes and go. It is pretty hard to pin point on which thread I want
to trace the object allocation.

To answer your last question, what I am really interested in finding out is
what type of object allocation makes GC happens more frequent. Randomly
taking snapshot of heap using jmap is absolutely not an idea way to do so
since not only it generates a giant file which is difficult to work with,
also it will pause the application and cause negative impact to the
application throughput. After I get the type of hot allocation, if it
happens to be an application level object type such as
com.Xyz.search.IndexReader, I can instrument the constructor to dump the
caller stack. People here also suggests it would be nice if we could dump
the allocation stack trace for some particular hot types.

I could propose the diff for your folks to review.

Thanks,

-Xiaobin

On Tue, Dec 14, 2010 at 11:58 PM, David Holmes <David.Holmes at oracle.com>wrote:

> Hi Xiaobin,
>
> The problem with tracing like this is that to be useful the tracing must be
> unobtrusive and be able to handle getting called millions of times (which is
> what will happen in those GC scenarios you describe). The sheer volume of
> data generated as you suggest below would overwhelm the app and be pretty
> hard to work with.
>
> Per-thread statistics of particular types (or of objects larger than a
> certain size) might be more useful, with a dump able to be requested
> on-demand.
>
> But I think you'd need to be able to combine this with heap dump info to be
> useful.
>
> It really depends on exactly what info you want to be able to deduce:
> simple number of objects of given types, hot allocation sites, hot threads,
> ...
>
> Cheers,
> David
>
> Xiaobin Lu said the following on 12/15/10 17:07:
>
>  Hi folks,
>>
>> I would like to propose a way to trace object allocation on Linux. On
>> Solaris, we have DTrace which is pretty nice. But on Linux, it is almost
>> impossible to do so. Correct me if I am wrong here.
>>
>> So I am thinking to add a manageable VM flag and let's call it
>> TraceObjectAllocation. When enabled, we can output something like:
>>
>> thread id: 10     class name: java/lang/reflect/Method             size:
>> 80 bytes
>> thread id: 10     class name: [Ljava/lang/Class;                    size:
>> 16 bytes
>> thread id: 10     class name: [C
>>                 size: 56 bytes
>> thread id: 10     class name: java/lang/reflect/Method            size: 80
>> bytes
>> thread id: 10     class name: [Ljava/lang/Class;                   size:
>> 16 bytes
>>
>> As you could imagine, this could be very useful to keep track of object
>> allocation behavior in the app. Some smart tool can take advantage of this
>> to print a histogram (like top 10 hot allocations) of object allocation. I
>> would like to know your thoughts and suggestions on this.
>>
>> I have a detailed proposal on this attached in PDF file.
>>
>> Thanks,
>>
>> -Xiaobin
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101215/8e050e58/attachment.html 

From y.s.ramakrishna at oracle.com  Wed Dec 15 10:06:00 2010
From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna)
Date: Wed, 15 Dec 2010 10:06:00 -0800
Subject: Trace object allocation flag proposal
In-Reply-To: <AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>	<4D087511.30902@oracle.com>
	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>
Message-ID: <4D090388.1040704@oracle.com>

Doesn't JVMTI already provide hooks (BCI?) for tracing allocation?
Perhaps that's found to be too obtrusive? Don't Java IDE's
use JVMTI to already deliver this kind of info to developers?

Pardon my naivette re JVMTI capabilities in this regard.
-- ramki
(java-serviceability-tools-illiterate)

On 12/15/10 10:00, Xiaobin Lu wrote:
> Thanks for your feedback, David.
> 
> Let me try to clarify with some more background information.
> 
> One of the problems many application has is the object allocation 
> problem (Duh ...). Over releases, GC becomes more and more frequent. It 
> is pretty hard for one single team to find out where the problem goes 
> wrong. The existing tool such as jhat or jmap is very hard to work with 
> giant heap dump file. So the flag I propose is mostly for diagnostic 
> purpose, it won't be enabled by default in production. Having said so, 
> if we make it as a manageable flag, we can turn it on when GC goes wild.
> 
> Another value this flag could provide is to find out why sometime OOM 
> occurs. For example, someone who wrote a search application on top of 
> Lucene framework suddenly found a crash due to OOM. The stack trace 
> points to Lucene code which is hard to instrument, so this flag could 
> provide insight to why the allocation fails. Maybe it is due to a 
> corrupted length value passed to "new byte[length];" etc.
> 
> I like your idea on per-thread basis, however, for a lot of web 
> application, thread comes and go. It is pretty hard to pin point on 
> which thread I want to trace the object allocation.
> 
> To answer your last question, what I am really interested in finding out 
> is what type of object allocation makes GC happens more frequent. 
> Randomly taking snapshot of heap using jmap is absolutely not an idea 
> way to do so since not only it generates a giant file which is difficult 
> to work with, also it will pause the application and cause negative 
> impact to the application throughput. After I get the type of hot 
> allocation, if it happens to be an application level object type such as 
> com.Xyz.search.IndexReader, I can instrument the constructor to dump the 
> caller stack. People here also suggests it would be nice if we could 
> dump the allocation stack trace for some particular hot types.
> 
> I could propose the diff for your folks to review.
> 
> Thanks,
> 
> -Xiaobin
> 
> On Tue, Dec 14, 2010 at 11:58 PM, David Holmes <David.Holmes at oracle.com 
> <mailto:David.Holmes at oracle.com>> wrote:
> 
>     Hi Xiaobin,
> 
>     The problem with tracing like this is that to be useful the tracing
>     must be unobtrusive and be able to handle getting called millions of
>     times (which is what will happen in those GC scenarios you
>     describe). The sheer volume of data generated as you suggest below
>     would overwhelm the app and be pretty hard to work with.
> 
>     Per-thread statistics of particular types (or of objects larger than
>     a certain size) might be more useful, with a dump able to be
>     requested on-demand.
> 
>     But I think you'd need to be able to combine this with heap dump
>     info to be useful.
> 
>     It really depends on exactly what info you want to be able to
>     deduce: simple number of objects of given types, hot allocation
>     sites, hot threads, ...
> 
>     Cheers,
>     David
> 
>     Xiaobin Lu said the following on 12/15/10 17:07:
> 
>         Hi folks,
> 
>         I would like to propose a way to trace object allocation on
>         Linux. On Solaris, we have DTrace which is pretty nice. But on
>         Linux, it is almost impossible to do so. Correct me if I am
>         wrong here.
> 
>         So I am thinking to add a manageable VM flag and let's call it
>         TraceObjectAllocation. When enabled, we can output something like:
> 
>         thread id: 10     class name: java/lang/reflect/Method          
>           size: 80 bytes
>         thread id: 10     class name: [Ljava/lang/Class;                
>            size: 16 bytes
>         thread id: 10     class name: [C                                
>                                   size: 56 bytes
>         thread id: 10     class name: java/lang/reflect/Method          
>          size: 80 bytes
>         thread id: 10     class name: [Ljava/lang/Class;                
>           size: 16 bytes
> 
>         As you could imagine, this could be very useful to keep track of
>         object allocation behavior in the app. Some smart tool can take
>         advantage of this to print a histogram (like top 10 hot
>         allocations) of object allocation. I would like to know your
>         thoughts and suggestions on this.
> 
>         I have a detailed proposal on this attached in PDF file.
> 
>         Thanks,
> 
>         -Xiaobin
> 
> 
> 

From jacklusf at gmail.com  Wed Dec 15 10:24:40 2010
From: jacklusf at gmail.com (Xiaobin Lu)
Date: Wed, 15 Dec 2010 10:24:40 -0800
Subject: Trace object allocation flag proposal
In-Reply-To: <4D090388.1040704@oracle.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>
	<4D087511.30902@oracle.com>
	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>
	<4D090388.1040704@oracle.com>
Message-ID: <AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>

One of the problems JVMTI has is that once it is enabled, it will fire all
kinds of events which will cause even more overheads. Correct me if I am
wrong here.

DTrace provides obj-alloc probes which is exactly what many people like to
have on Linux. And that is exactly what I am proposing here.

Thanks,

-Xiaobin

On Wed, Dec 15, 2010 at 10:06 AM, Y. S. Ramakrishna <
y.s.ramakrishna at oracle.com> wrote:

> Doesn't JVMTI already provide hooks (BCI?) for tracing allocation?
> Perhaps that's found to be too obtrusive? Don't Java IDE's
> use JVMTI to already deliver this kind of info to developers?
>
> Pardon my naivette re JVMTI capabilities in this regard.
> -- ramki
> (java-serviceability-tools-illiterate)
>
>
> On 12/15/10 10:00, Xiaobin Lu wrote:
>
>> Thanks for your feedback, David.
>>
>> Let me try to clarify with some more background information.
>>
>> One of the problems many application has is the object allocation problem
>> (Duh ...). Over releases, GC becomes more and more frequent. It is pretty
>> hard for one single team to find out where the problem goes wrong. The
>> existing tool such as jhat or jmap is very hard to work with giant heap dump
>> file. So the flag I propose is mostly for diagnostic purpose, it won't be
>> enabled by default in production. Having said so, if we make it as a
>> manageable flag, we can turn it on when GC goes wild.
>>
>> Another value this flag could provide is to find out why sometime OOM
>> occurs. For example, someone who wrote a search application on top of Lucene
>> framework suddenly found a crash due to OOM. The stack trace points to
>> Lucene code which is hard to instrument, so this flag could provide insight
>> to why the allocation fails. Maybe it is due to a corrupted length value
>> passed to "new byte[length];" etc.
>>
>> I like your idea on per-thread basis, however, for a lot of web
>> application, thread comes and go. It is pretty hard to pin point on which
>> thread I want to trace the object allocation.
>>
>> To answer your last question, what I am really interested in finding out
>> is what type of object allocation makes GC happens more frequent. Randomly
>> taking snapshot of heap using jmap is absolutely not an idea way to do so
>> since not only it generates a giant file which is difficult to work with,
>> also it will pause the application and cause negative impact to the
>> application throughput. After I get the type of hot allocation, if it
>> happens to be an application level object type such as
>> com.Xyz.search.IndexReader, I can instrument the constructor to dump the
>> caller stack. People here also suggests it would be nice if we could dump
>> the allocation stack trace for some particular hot types.
>>
>> I could propose the diff for your folks to review.
>>
>> Thanks,
>>
>> -Xiaobin
>>
>> On Tue, Dec 14, 2010 at 11:58 PM, David Holmes <David.Holmes at oracle.com<mailto:
>> David.Holmes at oracle.com>> wrote:
>>
>>    Hi Xiaobin,
>>
>>    The problem with tracing like this is that to be useful the tracing
>>    must be unobtrusive and be able to handle getting called millions of
>>    times (which is what will happen in those GC scenarios you
>>    describe). The sheer volume of data generated as you suggest below
>>    would overwhelm the app and be pretty hard to work with.
>>
>>    Per-thread statistics of particular types (or of objects larger than
>>    a certain size) might be more useful, with a dump able to be
>>    requested on-demand.
>>
>>    But I think you'd need to be able to combine this with heap dump
>>    info to be useful.
>>
>>    It really depends on exactly what info you want to be able to
>>    deduce: simple number of objects of given types, hot allocation
>>    sites, hot threads, ...
>>
>>    Cheers,
>>    David
>>
>>    Xiaobin Lu said the following on 12/15/10 17:07:
>>
>>        Hi folks,
>>
>>        I would like to propose a way to trace object allocation on
>>        Linux. On Solaris, we have DTrace which is pretty nice. But on
>>        Linux, it is almost impossible to do so. Correct me if I am
>>        wrong here.
>>
>>        So I am thinking to add a manageable VM flag and let's call it
>>        TraceObjectAllocation. When enabled, we can output something like:
>>
>>        thread id: 10     class name: java/lang/reflect/Method
>>        size: 80 bytes
>>        thread id: 10     class name: [Ljava/lang/Class;
>>         size: 16 bytes
>>        thread id: 10     class name: [C
>>                                size: 56 bytes
>>        thread id: 10     class name: java/lang/reflect/Method
>>       size: 80 bytes
>>        thread id: 10     class name: [Ljava/lang/Class;
>>        size: 16 bytes
>>
>>        As you could imagine, this could be very useful to keep track of
>>        object allocation behavior in the app. Some smart tool can take
>>        advantage of this to print a histogram (like top 10 hot
>>        allocations) of object allocation. I would like to know your
>>        thoughts and suggestions on this.
>>
>>        I have a detailed proposal on this attached in PDF file.
>>
>>        Thanks,
>>
>>        -Xiaobin
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101215/d9df125a/attachment-0001.html 

From Dmitry.Samersoff at oracle.com  Wed Dec 15 11:03:08 2010
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 15 Dec 2010 22:03:08 +0300
Subject: Trace object allocation flag proposal
In-Reply-To: <AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>	<4D087511.30902@oracle.com>	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>	<4D090388.1040704@oracle.com>
	<AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>
Message-ID: <4D0910EC.6080903@oracle.com>

Xiaobin,

We have three independent diagnostic systems in hotspot:

1. JVMTI
2. DTrace
3. Conventional logging

It's "not good" from long term perspective and I think we should unify it.

My personal opinion - we should have only JVMTI and make it as 
lightweight as possible.

-Dmitry



On 2010-12-15 21:24, Xiaobin Lu wrote:
> One of the problems JVMTI has is that once it is enabled, it will fire
> all kinds of events which will cause even more overheads. Correct me if
> I am wrong here.
>
> DTrace provides obj-alloc probes which is exactly what many people like
> to have on Linux. And that is exactly what I am proposing here.
>
> Thanks,
>
> -Xiaobin
>
> On Wed, Dec 15, 2010 at 10:06 AM, Y. S. Ramakrishna
> <y.s.ramakrishna at oracle.com <mailto:y.s.ramakrishna at oracle.com>> wrote:
>
>     Doesn't JVMTI already provide hooks (BCI?) for tracing allocation?
>     Perhaps that's found to be too obtrusive? Don't Java IDE's
>     use JVMTI to already deliver this kind of info to developers?
>
>     Pardon my naivette re JVMTI capabilities in this regard.
>     -- ramki
>     (java-serviceability-tools-illiterate)
>
>
>     On 12/15/10 10:00, Xiaobin Lu wrote:
>
>         Thanks for your feedback, David.
>
>         Let me try to clarify with some more background information.
>
>         One of the problems many application has is the object
>         allocation problem (Duh ...). Over releases, GC becomes more and
>         more frequent. It is pretty hard for one single team to find out
>         where the problem goes wrong. The existing tool such as jhat or
>         jmap is very hard to work with giant heap dump file. So the flag
>         I propose is mostly for diagnostic purpose, it won't be enabled
>         by default in production. Having said so, if we make it as a
>         manageable flag, we can turn it on when GC goes wild.
>
>         Another value this flag could provide is to find out why
>         sometime OOM occurs. For example, someone who wrote a search
>         application on top of Lucene framework suddenly found a crash
>         due to OOM. The stack trace points to Lucene code which is hard
>         to instrument, so this flag could provide insight to why the
>         allocation fails. Maybe it is due to a corrupted length value
>         passed to "new byte[length];" etc.
>
>         I like your idea on per-thread basis, however, for a lot of web
>         application, thread comes and go. It is pretty hard to pin point
>         on which thread I want to trace the object allocation.
>
>         To answer your last question, what I am really interested in
>         finding out is what type of object allocation makes GC happens
>         more frequent. Randomly taking snapshot of heap using jmap is
>         absolutely not an idea way to do so since not only it generates
>         a giant file which is difficult to work with, also it will pause
>         the application and cause negative impact to the application
>         throughput. After I get the type of hot allocation, if it
>         happens to be an application level object type such as
>         com.Xyz.search.IndexReader, I can instrument the constructor to
>         dump the caller stack. People here also suggests it would be
>         nice if we could dump the allocation stack trace for some
>         particular hot types.
>
>         I could propose the diff for your folks to review.
>
>         Thanks,
>
>         -Xiaobin
>
>         On Tue, Dec 14, 2010 at 11:58 PM, David Holmes
>         <David.Holmes at oracle.com <mailto:David.Holmes at oracle.com>
>         <mailto:David.Holmes at oracle.com
>         <mailto:David.Holmes at oracle.com>>> wrote:
>
>             Hi Xiaobin,
>
>             The problem with tracing like this is that to be useful the
>         tracing
>             must be unobtrusive and be able to handle getting called
>         millions of
>             times (which is what will happen in those GC scenarios you
>             describe). The sheer volume of data generated as you suggest
>         below
>             would overwhelm the app and be pretty hard to work with.
>
>             Per-thread statistics of particular types (or of objects
>         larger than
>             a certain size) might be more useful, with a dump able to be
>             requested on-demand.
>
>             But I think you'd need to be able to combine this with heap dump
>             info to be useful.
>
>             It really depends on exactly what info you want to be able to
>             deduce: simple number of objects of given types, hot allocation
>             sites, hot threads, ...
>
>             Cheers,
>             David
>
>             Xiaobin Lu said the following on 12/15/10 17:07:
>
>                 Hi folks,
>
>                 I would like to propose a way to trace object allocation on
>                 Linux. On Solaris, we have DTrace which is pretty nice.
>         But on
>                 Linux, it is almost impossible to do so. Correct me if I am
>                 wrong here.
>
>                 So I am thinking to add a manageable VM flag and let's
>         call it
>                 TraceObjectAllocation. When enabled, we can output
>         something like:
>
>                 thread id: 10     class name: java/lang/reflect/Method
>                           size: 80 bytes
>                 thread id: 10     class name: [Ljava/lang/Class;
>                            size: 16 bytes
>                 thread id: 10     class name: [C
>                                                   size: 56 bytes
>                 thread id: 10     class name: java/lang/reflect/Method
>                          size: 80 bytes
>                 thread id: 10     class name: [Ljava/lang/Class;
>                           size: 16 bytes
>
>                 As you could imagine, this could be very useful to keep
>         track of
>                 object allocation behavior in the app. Some smart tool
>         can take
>                 advantage of this to print a histogram (like top 10 hot
>                 allocations) of object allocation. I would like to know your
>                 thoughts and suggestions on this.
>
>                 I have a detailed proposal on this attached in PDF file.
>
>                 Thanks,
>
>                 -Xiaobin
>
>
>
>


-- 
Dmitry Samersoff
J2SE Sustaining team, SPB04
* Give Rabbit time and he'll always get the answer ...

From y.s.ramakrishna at oracle.com  Wed Dec 15 11:21:11 2010
From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna)
Date: Wed, 15 Dec 2010 11:21:11 -0800
Subject: Trace object allocation flag proposal
In-Reply-To: <AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>	<4D087511.30902@oracle.com>	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>	<4D090388.1040704@oracle.com>
	<AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>
Message-ID: <4D091527.2010404@oracle.com>



On 12/15/10 10:24, Xiaobin Lu wrote:
> One of the problems JVMTI has is that once it is enabled, it will fire 
> all kinds of events which will cause even more overheads. Correct me if 
> I am wrong here.

I didn't think JVMTI is "all or nothing" (if i understood yr statement).
But i will let the serviceability/JVMTI cognoscenti comment.

> 
> DTrace provides obj-alloc probes which is exactly what many people like 
> to have on Linux. And that is exactly what I am proposing here.

Ah, i see. (Sorry for not reading through yr proposal before talking.)
But orthogonally to yr proposal, which is narrowly targeted to addressing
this specific issue related to object allocation,
why not use Linux system tap or other to mimic as much as possible the
Dtrace probes provided by the JVM, rather than making this point fix (if
i understand yr proposal) for just one aspect of what's offered by
Dtrace?

Over to the serviceability folk; and out.
-- ramki

> 
> Thanks,
> 
> -Xiaobin
> 
> On Wed, Dec 15, 2010 at 10:06 AM, Y. S. Ramakrishna 
> <y.s.ramakrishna at oracle.com <mailto:y.s.ramakrishna at oracle.com>> wrote:
> 
>     Doesn't JVMTI already provide hooks (BCI?) for tracing allocation?
>     Perhaps that's found to be too obtrusive? Don't Java IDE's
>     use JVMTI to already deliver this kind of info to developers?
> 
>     Pardon my naivette re JVMTI capabilities in this regard.
>     -- ramki
>     (java-serviceability-tools-illiterate)
> 
> 
>     On 12/15/10 10:00, Xiaobin Lu wrote:
> 
>         Thanks for your feedback, David.
> 
>         Let me try to clarify with some more background information.
> 
>         One of the problems many application has is the object
>         allocation problem (Duh ...). Over releases, GC becomes more and
>         more frequent. It is pretty hard for one single team to find out
>         where the problem goes wrong. The existing tool such as jhat or
>         jmap is very hard to work with giant heap dump file. So the flag
>         I propose is mostly for diagnostic purpose, it won't be enabled
>         by default in production. Having said so, if we make it as a
>         manageable flag, we can turn it on when GC goes wild.
> 
>         Another value this flag could provide is to find out why
>         sometime OOM occurs. For example, someone who wrote a search
>         application on top of Lucene framework suddenly found a crash
>         due to OOM. The stack trace points to Lucene code which is hard
>         to instrument, so this flag could provide insight to why the
>         allocation fails. Maybe it is due to a corrupted length value
>         passed to "new byte[length];" etc.
> 
>         I like your idea on per-thread basis, however, for a lot of web
>         application, thread comes and go. It is pretty hard to pin point
>         on which thread I want to trace the object allocation.
> 
>         To answer your last question, what I am really interested in
>         finding out is what type of object allocation makes GC happens
>         more frequent. Randomly taking snapshot of heap using jmap is
>         absolutely not an idea way to do so since not only it generates
>         a giant file which is difficult to work with, also it will pause
>         the application and cause negative impact to the application
>         throughput. After I get the type of hot allocation, if it
>         happens to be an application level object type such as
>         com.Xyz.search.IndexReader, I can instrument the constructor to
>         dump the caller stack. People here also suggests it would be
>         nice if we could dump the allocation stack trace for some
>         particular hot types.
> 
>         I could propose the diff for your folks to review.
> 
>         Thanks,
> 
>         -Xiaobin
> 
>         On Tue, Dec 14, 2010 at 11:58 PM, David Holmes
>         <David.Holmes at oracle.com <mailto:David.Holmes at oracle.com>
>         <mailto:David.Holmes at oracle.com
>         <mailto:David.Holmes at oracle.com>>> wrote:
> 
>            Hi Xiaobin,
> 
>            The problem with tracing like this is that to be useful the
>         tracing
>            must be unobtrusive and be able to handle getting called
>         millions of
>            times (which is what will happen in those GC scenarios you
>            describe). The sheer volume of data generated as you suggest
>         below
>            would overwhelm the app and be pretty hard to work with.
> 
>            Per-thread statistics of particular types (or of objects
>         larger than
>            a certain size) might be more useful, with a dump able to be
>            requested on-demand.
> 
>            But I think you'd need to be able to combine this with heap dump
>            info to be useful.
> 
>            It really depends on exactly what info you want to be able to
>            deduce: simple number of objects of given types, hot allocation
>            sites, hot threads, ...
> 
>            Cheers,
>            David
> 
>            Xiaobin Lu said the following on 12/15/10 17:07:
> 
>                Hi folks,
> 
>                I would like to propose a way to trace object allocation on
>                Linux. On Solaris, we have DTrace which is pretty nice.
>         But on
>                Linux, it is almost impossible to do so. Correct me if I am
>                wrong here.
> 
>                So I am thinking to add a manageable VM flag and let's
>         call it
>                TraceObjectAllocation. When enabled, we can output
>         something like:
> 
>                thread id: 10     class name: java/lang/reflect/Method  
>                          size: 80 bytes
>                thread id: 10     class name: [Ljava/lang/Class;        
>                           size: 16 bytes
>                thread id: 10     class name: [C                        
>                                                  size: 56 bytes
>                thread id: 10     class name: java/lang/reflect/Method  
>                         size: 80 bytes
>                thread id: 10     class name: [Ljava/lang/Class;        
>                          size: 16 bytes
> 
>                As you could imagine, this could be very useful to keep
>         track of
>                object allocation behavior in the app. Some smart tool
>         can take
>                advantage of this to print a histogram (like top 10 hot
>                allocations) of object allocation. I would like to know your
>                thoughts and suggestions on this.
> 
>                I have a detailed proposal on this attached in PDF file.
> 
>                Thanks,
> 
>                -Xiaobin
> 
> 
> 
> 

From guanxiaohua at gmail.com  Wed Dec 15 11:28:50 2010
From: guanxiaohua at gmail.com (Tony Guan)
Date: Wed, 15 Dec 2010 13:28:50 -0600
Subject: Trace object allocation flag proposal
Message-ID: <AANLkTim8PeWK85pcypsv7rNtc9w-9747qwJGG4j9hRDY@mail.gmail.com>

Hi Xiaobin,

A reminder for the allocation site profiling, you can check JVMTI
sample heapTracker or hprof, this might be what you need for the time
being.

As to the question what type of the objects will cause the most
garbage collections,I think it's equivalent to the question "At what
point the heap is filled up, and what the next allocation request
looks like."  I think the stack trace at the GC time is more relevant
to this question than the next allocation type.

If you are concerned about the overhead using JVMTI, I am sure that if
you don't enable a certain event type, the callbacks will not be
called for that event. The overhead is just the similar to DTrace.
Please refer to the following src code in OpenJDK:

inline void post_allocation_notify(KlassHandle klass, oop obj) {
  // support low memory notifications (no-op if not enabled)
  LowMemoryDetector::detect_low_memory_for_collected_pools();
  // support for JVMTI VMObjectAlloc event (no-op if not enabled)
	  JvmtiExport::vm_object_alloc_event_collector(obj);
  if (DTraceAllocProbes) {
    // support for Dtrace object alloc event (no-op most of the time)
    if (klass() != NULL && klass()->klass_part()->name() != NULL) {
      SharedRuntime::dtrace_object_alloc(obj);
    }
  }
}


Thanks.

Tony (Xiaohua Guan)
>
> ? 1. Re: Trace object allocation flag proposal (David Holmes)
> ? 2. hg: jdk7/hotspot-rt/hotspot: 2 new changesets
> ? ? ?(staffan.larsen at oracle.com)
> ? 3. Re: Trace object allocation flag proposal (Xiaobin Lu)
> ? 4. Re: Trace object allocation flag proposal (Y. S. Ramakrishna)
> ? 5. Re: Trace object allocation flag proposal (Xiaobin Lu)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Dec 2010 17:58:09 +1000
> From: David Holmes <David.Holmes at oracle.com>
> Subject: Re: Trace object allocation flag proposal
> To: Xiaobin Lu <jacklusf at gmail.com>
> Cc: hotspot-runtime-dev at openjdk.java.net
> Message-ID: <4D087511.30902 at oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Xiaobin,
>
> The problem with tracing like this is that to be useful the tracing must
> be unobtrusive and be able to handle getting called millions of times
> (which is what will happen in those GC scenarios you describe). The
> sheer volume of data generated as you suggest below would overwhelm the
> app and be pretty hard to work with.
>
> Per-thread statistics of particular types (or of objects larger than a
> certain size) might be more useful, with a dump able to be requested
> on-demand.
>
> But I think you'd need to be able to combine this with heap dump info to
> be useful.
>
> It really depends on exactly what info you want to be able to deduce:
> simple number of objects of given types, hot allocation sites, hot
> threads, ...
>
> Cheers,
> David
>
> Xiaobin Lu said the following on 12/15/10 17:07:
>> Hi folks,
>>
>> I would like to propose a way to trace object allocation on Linux. On
>> Solaris, we have DTrace which is pretty nice. But on Linux, it is almost
>> impossible to do so. Correct me if I am wrong here.
>>
>> So I am thinking to add a manageable VM flag and let's call it
>> TraceObjectAllocation. When enabled, we can output something like:
>>
>> thread id: 10 ? ? class name: java/lang/reflect/Method ? ? ? ? ? ? size:
>> 80 bytes
>> thread id: 10 ? ? class name: [Ljava/lang/Class;
>> ? size: 16 bytes
>> thread id: 10 ? ? class name: [C
>> ? ? ? ? ? ? ? ? ? ? ? ? ?size: 56 bytes
>> thread id: 10 ? ? class name: java/lang/reflect/Method ? ? ? ? ? ?size:
>> 80 bytes
>> thread id: 10 ? ? class name: [Ljava/lang/Class; ? ? ? ? ? ? ? ? ? size:
>> 16 bytes
>>
>> As you could imagine, this could be very useful to keep track of object
>> allocation behavior in the app. Some smart tool can take advantage of
>> this to print a histogram (like top 10 hot allocations) of object
>> allocation. I would like to know your thoughts and suggestions on this.
>>
>> I have a detailed proposal on this attached in PDF file.
>>
>> Thanks,
>>
>> -Xiaobin
> Message: 3
> Date: Wed, 15 Dec 2010 10:00:50 -0800
> From: Xiaobin Lu <jacklusf at gmail.com>
> Subject: Re: Trace object allocation flag proposal
> To: David Holmes <David.Holmes at oracle.com>
> Cc: hotspot-runtime-dev at openjdk.java.net
> Message-ID:
> ? ? ? ?<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks for your feedback, David.
>
> Let me try to clarify with some more background information.
>
> One of the problems many application has is the object allocation problem
> (Duh ...). Over releases, GC becomes more and more frequent. It is pretty
> hard for one single team to find out where the problem goes wrong. The
> existing tool such as jhat or jmap is very hard to work with giant heap dump
> file. So the flag I propose is mostly for diagnostic purpose, it won't be
> enabled by default in production. Having said so, if we make it as a
> manageable flag, we can turn it on when GC goes wild.
>
> Another value this flag could provide is to find out why sometime OOM
> occurs. For example, someone who wrote a search application on top of Lucene
> framework suddenly found a crash due to OOM. The stack trace points to
> Lucene code which is hard to instrument, so this flag could provide insight
> to why the allocation fails. Maybe it is due to a corrupted length value
> passed to "new byte[length];" etc.
>
> I like your idea on per-thread basis, however, for a lot of web application,
> thread comes and go. It is pretty hard to pin point on which thread I want
> to trace the object allocation.
>
> To answer your last question, what I am really interested in finding out is
> what type of object allocation makes GC happens more frequent. Randomly
> taking snapshot of heap using jmap is absolutely not an idea way to do so
> since not only it generates a giant file which is difficult to work with,
> also it will pause the application and cause negative impact to the
> application throughput. After I get the type of hot allocation, if it
> happens to be an application level object type such as
> com.Xyz.search.IndexReader, I can instrument the constructor to dump the
> caller stack. People here also suggests it would be nice if we could dump
> the allocation stack trace for some particular hot types.
>
> I could propose the diff for your folks to review.
>
> Thanks,
>
> -Xiaobin
>
> On Tue, Dec 14, 2010 at 11:58 PM, David Holmes <David.Holmes at oracle.com>wrote:
>
>> Hi Xiaobin,
>>
>> The problem with tracing like this is that to be useful the tracing must be
>> unobtrusive and be able to handle getting called millions of times (which is
>> what will happen in those GC scenarios you describe). The sheer volume of
>> data generated as you suggest below would overwhelm the app and be pretty
>> hard to work with.
>>
>> Per-thread statistics of particular types (or of objects larger than a
>> certain size) might be more useful, with a dump able to be requested
>> on-demand.
>>
>> But I think you'd need to be able to combine this with heap dump info to be
>> useful.
>>
>> It really depends on exactly what info you want to be able to deduce:
>> simple number of objects of given types, hot allocation sites, hot threads,
>> ...
>>
>> Cheers,
>> David
>>
>> Xiaobin Lu said the following on 12/15/10 17:07:
>>
>> ?Hi folks,
>>>
>>> I would like to propose a way to trace object allocation on Linux. On
>>> Solaris, we have DTrace which is pretty nice. But on Linux, it is almost
>>> impossible to do so. Correct me if I am wrong here.
>>>
>>> So I am thinking to add a manageable VM flag and let's call it
>>> TraceObjectAllocation. When enabled, we can output something like:
>>>
>>> thread id: 10 ? ? class name: java/lang/reflect/Method ? ? ? ? ? ? size:
>>> 80 bytes
>>> thread id: 10 ? ? class name: [Ljava/lang/Class; ? ? ? ? ? ? ? ? ? ?size:
>>> 16 bytes
>>> thread id: 10 ? ? class name: [C
>>> ? ? ? ? ? ? ? ? size: 56 bytes
>>> thread id: 10 ? ? class name: java/lang/reflect/Method ? ? ? ? ? ?size: 80
>>> bytes
>>> thread id: 10 ? ? class name: [Ljava/lang/Class; ? ? ? ? ? ? ? ? ? size:
>>> 16 bytes
>>>
>>> As you could imagine, this could be very useful to keep track of object
>>> allocation behavior in the app. Some smart tool can take advantage of this
>>> to print a histogram (like top 10 hot allocations) of object allocation. I
>>> would like to know your thoughts and suggestions on this.
>>>
>>> I have a detailed proposal on this attached in PDF file.
>>>
>>> Thanks,
>>>
>>> -Xiaobin
>>>
>>>
>>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101215/8e050e58/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Wed, 15 Dec 2010 10:06:00 -0800
> From: "Y. S. Ramakrishna" <y.s.ramakrishna at oracle.com>
> Subject: Re: Trace object allocation flag proposal
> To: Xiaobin Lu <jacklusf at gmail.com>
> Cc: hotspot-runtime-dev at openjdk.java.net
> Message-ID: <4D090388.1040704 at oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Doesn't JVMTI already provide hooks (BCI?) for tracing allocation?
> Perhaps that's found to be too obtrusive? Don't Java IDE's
> use JVMTI to already deliver this kind of info to developers?
>
> Pardon my naivette re JVMTI capabilities in this regard.
> -- ramki
> (java-serviceability-tools-illiterate)
>
> On 12/15/10 10:00, Xiaobin Lu wrote:
>> Thanks for your feedback, David.
>>
>> Let me try to clarify with some more background information.
>>
>> One of the problems many application has is the object allocation
>> problem (Duh ...). Over releases, GC becomes more and more frequent. It
>> is pretty hard for one single team to find out where the problem goes
>> wrong. The existing tool such as jhat or jmap is very hard to work with
>> giant heap dump file. So the flag I propose is mostly for diagnostic
>> purpose, it won't be enabled by default in production. Having said so,
>> if we make it as a manageable flag, we can turn it on when GC goes wild.
>>
>> Another value this flag could provide is to find out why sometime OOM
>> occurs. For example, someone who wrote a search application on top of
>> Lucene framework suddenly found a crash due to OOM. The stack trace
>> points to Lucene code which is hard to instrument, so this flag could
>> provide insight to why the allocation fails. Maybe it is due to a
>> corrupted length value passed to "new byte[length];" etc.
>>
>> I like your idea on per-thread basis, however, for a lot of web
>> application, thread comes and go. It is pretty hard to pin point on
>> which thread I want to trace the object allocation.
>>
>> To answer your last question, what I am really interested in finding out
>> is what type of object allocation makes GC happens more frequent.
>> Randomly taking snapshot of heap using jmap is absolutely not an idea
>> way to do so since not only it generates a giant file which is difficult
>> to work with, also it will pause the application and cause negative
>> impact to the application throughput. After I get the type of hot
>> allocation, if it happens to be an application level object type such as
>> com.Xyz.search.IndexReader, I can instrument the constructor to dump the
>> caller stack. People here also suggests it would be nice if we could
>> dump the allocation stack trace for some particular hot types.
>>
>> I could propose the diff for your folks to review.
>>
>> Thanks,
>>
>> -Xiaobin
>>
>> On Tue, Dec 14, 2010 at 11:58 PM, David Holmes <David.Holmes at oracle.com
>> <mailto:David.Holmes at oracle.com>> wrote:
>>
>> ? ? Hi Xiaobin,
>>
>> ? ? The problem with tracing like this is that to be useful the tracing
>> ? ? must be unobtrusive and be able to handle getting called millions of
>> ? ? times (which is what will happen in those GC scenarios you
>> ? ? describe). The sheer volume of data generated as you suggest below
>> ? ? would overwhelm the app and be pretty hard to work with.
>>
>> ? ? Per-thread statistics of particular types (or of objects larger than
>> ? ? a certain size) might be more useful, with a dump able to be
>> ? ? requested on-demand.
>>
>> ? ? But I think you'd need to be able to combine this with heap dump
>> ? ? info to be useful.
>>
>> ? ? It really depends on exactly what info you want to be able to
>> ? ? deduce: simple number of objects of given types, hot allocation
>> ? ? sites, hot threads, ...
>>
>> ? ? Cheers,
>> ? ? David
>>
>> ? ? Xiaobin Lu said the following on 12/15/10 17:07:
>>
>> ? ? ? ? Hi folks,
>>
>> ? ? ? ? I would like to propose a way to trace object allocation on
>> ? ? ? ? Linux. On Solaris, we have DTrace which is pretty nice. But on
>> ? ? ? ? Linux, it is almost impossible to do so. Correct me if I am
>> ? ? ? ? wrong here.
>>
>> ? ? ? ? So I am thinking to add a manageable VM flag and let's call it
>> ? ? ? ? TraceObjectAllocation. When enabled, we can output something like:
>>
>> ? ? ? ? thread id: 10 ? ? class name: java/lang/reflect/Method
>> ? ? ? ? ? size: 80 bytes
>> ? ? ? ? thread id: 10 ? ? class name: [Ljava/lang/Class;
>> ? ? ? ? ? ?size: 16 bytes
>> ? ? ? ? thread id: 10 ? ? class name: [C
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? size: 56 bytes
>> ? ? ? ? thread id: 10 ? ? class name: java/lang/reflect/Method
>> ? ? ? ? ?size: 80 bytes
>> ? ? ? ? thread id: 10 ? ? class name: [Ljava/lang/Class;
>> ? ? ? ? ? size: 16 bytes
>>
>> ? ? ? ? As you could imagine, this could be very useful to keep track of
>> ? ? ? ? object allocation behavior in the app. Some smart tool can take
>> ? ? ? ? advantage of this to print a histogram (like top 10 hot
>> ? ? ? ? allocations) of object allocation. I would like to know your
>> ? ? ? ? thoughts and suggestions on this.
>>
>> ? ? ? ? I have a detailed proposal on this attached in PDF file.
>>
>> ? ? ? ? Thanks,
>>
>> ? ? ? ? -Xiaobin
>>
>>
>>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 15 Dec 2010 10:24:40 -0800
> From: Xiaobin Lu <jacklusf at gmail.com>
> Subject: Re: Trace object allocation flag proposal
> To: Y.S.Ramakrishna at oracle.com
> Cc: hotspot-runtime-dev at openjdk.java.net
> Message-ID:
> ? ? ? ?<AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> One of the problems JVMTI has is that once it is enabled, it will fire all
> kinds of events which will cause even more overheads. Correct me if I am
> wrong here.
>
> DTrace provides obj-alloc probes which is exactly what many people like to
> have on Linux. And that is exactly what I am proposing here.
>
> Thanks,
>
> -Xiaobin
>
> On Wed, Dec 15, 2010 at 10:06 AM, Y. S. Ramakrishna <
> y.s.ramakrishna at oracle.com> wrote:
>
>> Doesn't JVMTI already provide hooks (BCI?) for tracing allocation?
>> Perhaps that's found to be too obtrusive? Don't Java IDE's
>> use JVMTI to already deliver this kind of info to developers?
>>
>> Pardon my naivette re JVMTI capabilities in this regard.
>> -- ramki
>> (java-serviceability-tools-illiterate)
>>
>>
>> On 12/15/10 10:00, Xiaobin Lu wrote:
>>
>>> Thanks for your feedback, David.
>>>
>>> Let me try to clarify with some more background information.
>>>
>>> One of the problems many application has is the object allocation problem
>>> (Duh ...). Over releases, GC becomes more and more frequent. It is pretty
>>> hard for one single team to find out where the problem goes wrong. The
>>> existing tool such as jhat or jmap is very hard to work with giant heap dump
>>> file. So the flag I propose is mostly for diagnostic purpose, it won't be
>>> enabled by default in production. Having said so, if we make it as a
>>> manageable flag, we can turn it on when GC goes wild.
>>>
>>> Another value this flag could provide is to find out why sometime OOM
>>> occurs. For example, someone who wrote a search application on top of Lucene
>>> framework suddenly found a crash due to OOM. The stack trace points to
>>> Lucene code which is hard to instrument, so this flag could provide insight
>>> to why the allocation fails. Maybe it is due to a corrupted length value
>>> passed to "new byte[length];" etc.
>>>
>>> I like your idea on per-thread basis, however, for a lot of web
>>> application, thread comes and go. It is pretty hard to pin point on which
>>> thread I want to trace the object allocation.
>>>
>>> To answer your last question, what I am really interested in finding out
>>> is what type of object allocation makes GC happens more frequent. Randomly
>>> taking snapshot of heap using jmap is absolutely not an idea way to do so
>>> since not only it generates a giant file which is difficult to work with,
>>> also it will pause the application and cause negative impact to the
>>> application throughput. After I get the type of hot allocation, if it
>>> happens to be an application level object type such as
>>> com.Xyz.search.IndexReader, I can instrument the constructor to dump the
>>> caller stack. People here also suggests it would be nice if we could dump
>>> the allocation stack trace for some particular hot types.
>>>
>>> I could propose the diff for your folks to review.
>>>
>>> Thanks,
>>>
>>> -Xiaobin
>>>
>>> On Tue, Dec 14, 2010 at 11:58 PM, David Holmes <David.Holmes at oracle.com<mailto:
>>> David.Holmes at oracle.com>> wrote:
>>>
>>> ? ?Hi Xiaobin,
>>>
>>> ? ?The problem with tracing like this is that to be useful the tracing
>>> ? ?must be unobtrusive and be able to handle getting called millions of
>>> ? ?times (which is what will happen in those GC scenarios you
>>> ? ?describe). The sheer volume of data generated as you suggest below
>>> ? ?would overwhelm the app and be pretty hard to work with.
>>>
>>> ? ?Per-thread statistics of particular types (or of objects larger than
>>> ? ?a certain size) might be more useful, with a dump able to be
>>> ? ?requested on-demand.
>>>
>>> ? ?But I think you'd need to be able to combine this with heap dump
>>> ? ?info to be useful.
>>>
>>> ? ?It really depends on exactly what info you want to be able to
>>> ? ?deduce: simple number of objects of given types, hot allocation
>>> ? ?sites, hot threads, ...
>>>
>>> ? ?Cheers,
>>> ? ?David
>>>
>>> ? ?Xiaobin Lu said the following on 12/15/10 17:07:
>>>
>>> ? ? ? ?Hi folks,
>>>
>>> ? ? ? ?I would like to propose a way to trace object allocation on
>>> ? ? ? ?Linux. On Solaris, we have DTrace which is pretty nice. But on
>>> ? ? ? ?Linux, it is almost impossible to do so. Correct me if I am
>>> ? ? ? ?wrong here.
>>>
>>> ? ? ? ?So I am thinking to add a manageable VM flag and let's call it
>>> ? ? ? ?TraceObjectAllocation. When enabled, we can output something like:
>>>
>>> ? ? ? ?thread id: 10 ? ? class name: java/lang/reflect/Method
>>> ? ? ? ?size: 80 bytes
>>> ? ? ? ?thread id: 10 ? ? class name: [Ljava/lang/Class;
>>> ? ? ? ? size: 16 bytes
>>> ? ? ? ?thread id: 10 ? ? class name: [C
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?size: 56 bytes
>>> ? ? ? ?thread id: 10 ? ? class name: java/lang/reflect/Method
>>> ? ? ? size: 80 bytes
>>> ? ? ? ?thread id: 10 ? ? class name: [Ljava/lang/Class;
>>> ? ? ? ?size: 16 bytes
>>>
>>> ? ? ? ?As you could imagine, this could be very useful to keep track of
>>> ? ? ? ?object allocation behavior in the app. Some smart tool can take
>>> ? ? ? ?advantage of this to print a histogram (like top 10 hot
>>> ? ? ? ?allocations) of object allocation. I would like to know your
>>> ? ? ? ?thoughts and suggestions on this.
>>>
>>> ? ? ? ?I have a detailed proposal on this attached in PDF file.
>>>
>>> ? ? ? ?Thanks,
>>>
>>> ? ? ? ?-Xiaobin
>>>
>>>
>>>
>>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101215/d9df125a/attachment.html
>
> End of hotspot-runtime-dev Digest, Vol 42, Issue 18
> ***************************************************
>

From jacklusf at gmail.com  Wed Dec 15 11:38:15 2010
From: jacklusf at gmail.com (Xiaobin Lu)
Date: Wed, 15 Dec 2010 11:38:15 -0800
Subject: Trace object allocation flag proposal
In-Reply-To: <4D091527.2010404@oracle.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>
	<4D087511.30902@oracle.com>
	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>
	<4D090388.1040704@oracle.com>
	<AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>
	<4D091527.2010404@oracle.com>
Message-ID: <AANLkTimtuSFQBW+rrQYp=n-1rr0EinygTmmrpcUMRqN8@mail.gmail.com>

Object allocation seems to be a general problem here at least. For many
application developers, they think object allocation is cheap. Recently, we
uncovered several problems here such as over-allocating StringBuilder object
and use StringBuilder(s) with default constructor which leads to constantly
array copy and etc.

Linux system tap is in development stage and not available in early release
which is most companies probably use. Surprisingly enough, people are
reluctant to move to new platforms, even scare to upgrade their JDK to later
version of JDK 6 update release or 64 bit jdk.

I had this hack in my local VM here and I really think we should make it
into openjdk so that more people can access that functionality.

-Xiaobin

On Wed, Dec 15, 2010 at 11:21 AM, Y. S. Ramakrishna <
y.s.ramakrishna at oracle.com> wrote:

>
>
> On 12/15/10 10:24, Xiaobin Lu wrote:
>
>> One of the problems JVMTI has is that once it is enabled, it will fire all
>> kinds of events which will cause even more overheads. Correct me if I am
>> wrong here.
>>
>
> I didn't think JVMTI is "all or nothing" (if i understood yr statement).
> But i will let the serviceability/JVMTI cognoscenti comment.
>
>
>
>> DTrace provides obj-alloc probes which is exactly what many people like to
>> have on Linux. And that is exactly what I am proposing here.
>>
>
> Ah, i see. (Sorry for not reading through yr proposal before talking.)
> But orthogonally to yr proposal, which is narrowly targeted to addressing
> this specific issue related to object allocation,
> why not use Linux system tap or other to mimic as much as possible the
> Dtrace probes provided by the JVM, rather than making this point fix (if
> i understand yr proposal) for just one aspect of what's offered by
> Dtrace?
>
> Over to the serviceability folk; and out.
> -- ramki
>
>
>> Thanks,
>>
>> -Xiaobin
>>
>>
>> On Wed, Dec 15, 2010 at 10:06 AM, Y. S. Ramakrishna <
>> y.s.ramakrishna at oracle.com <mailto:y.s.ramakrishna at oracle.com>> wrote:
>>
>>    Doesn't JVMTI already provide hooks (BCI?) for tracing allocation?
>>    Perhaps that's found to be too obtrusive? Don't Java IDE's
>>    use JVMTI to already deliver this kind of info to developers?
>>
>>    Pardon my naivette re JVMTI capabilities in this regard.
>>    -- ramki
>>    (java-serviceability-tools-illiterate)
>>
>>
>>    On 12/15/10 10:00, Xiaobin Lu wrote:
>>
>>        Thanks for your feedback, David.
>>
>>        Let me try to clarify with some more background information.
>>
>>        One of the problems many application has is the object
>>        allocation problem (Duh ...). Over releases, GC becomes more and
>>        more frequent. It is pretty hard for one single team to find out
>>        where the problem goes wrong. The existing tool such as jhat or
>>        jmap is very hard to work with giant heap dump file. So the flag
>>        I propose is mostly for diagnostic purpose, it won't be enabled
>>        by default in production. Having said so, if we make it as a
>>        manageable flag, we can turn it on when GC goes wild.
>>
>>        Another value this flag could provide is to find out why
>>        sometime OOM occurs. For example, someone who wrote a search
>>        application on top of Lucene framework suddenly found a crash
>>        due to OOM. The stack trace points to Lucene code which is hard
>>        to instrument, so this flag could provide insight to why the
>>        allocation fails. Maybe it is due to a corrupted length value
>>        passed to "new byte[length];" etc.
>>
>>        I like your idea on per-thread basis, however, for a lot of web
>>        application, thread comes and go. It is pretty hard to pin point
>>        on which thread I want to trace the object allocation.
>>
>>        To answer your last question, what I am really interested in
>>        finding out is what type of object allocation makes GC happens
>>        more frequent. Randomly taking snapshot of heap using jmap is
>>        absolutely not an idea way to do so since not only it generates
>>        a giant file which is difficult to work with, also it will pause
>>        the application and cause negative impact to the application
>>        throughput. After I get the type of hot allocation, if it
>>        happens to be an application level object type such as
>>        com.Xyz.search.IndexReader, I can instrument the constructor to
>>        dump the caller stack. People here also suggests it would be
>>        nice if we could dump the allocation stack trace for some
>>        particular hot types.
>>
>>        I could propose the diff for your folks to review.
>>
>>        Thanks,
>>
>>        -Xiaobin
>>
>>        On Tue, Dec 14, 2010 at 11:58 PM, David Holmes
>>        <David.Holmes at oracle.com <mailto:David.Holmes at oracle.com>
>>        <mailto:David.Holmes at oracle.com
>>        <mailto:David.Holmes at oracle.com>>> wrote:
>>
>>           Hi Xiaobin,
>>
>>           The problem with tracing like this is that to be useful the
>>        tracing
>>           must be unobtrusive and be able to handle getting called
>>        millions of
>>           times (which is what will happen in those GC scenarios you
>>           describe). The sheer volume of data generated as you suggest
>>        below
>>           would overwhelm the app and be pretty hard to work with.
>>
>>           Per-thread statistics of particular types (or of objects
>>        larger than
>>           a certain size) might be more useful, with a dump able to be
>>           requested on-demand.
>>
>>           But I think you'd need to be able to combine this with heap dump
>>           info to be useful.
>>
>>           It really depends on exactly what info you want to be able to
>>           deduce: simple number of objects of given types, hot allocation
>>           sites, hot threads, ...
>>
>>           Cheers,
>>           David
>>
>>           Xiaobin Lu said the following on 12/15/10 17:07:
>>
>>               Hi folks,
>>
>>               I would like to propose a way to trace object allocation on
>>               Linux. On Solaris, we have DTrace which is pretty nice.
>>        But on
>>               Linux, it is almost impossible to do so. Correct me if I am
>>               wrong here.
>>
>>               So I am thinking to add a manageable VM flag and let's
>>        call it
>>               TraceObjectAllocation. When enabled, we can output
>>        something like:
>>
>>               thread id: 10     class name: java/lang/reflect/Method
>>                     size: 80 bytes
>>               thread id: 10     class name: [Ljava/lang/Class;
>>                      size: 16 bytes
>>               thread id: 10     class name: [C
>>                                             size: 56 bytes
>>               thread id: 10     class name: java/lang/reflect/Method
>>                    size: 80 bytes
>>               thread id: 10     class name: [Ljava/lang/Class;
>>                     size: 16 bytes
>>
>>               As you could imagine, this could be very useful to keep
>>        track of
>>               object allocation behavior in the app. Some smart tool
>>        can take
>>               advantage of this to print a histogram (like top 10 hot
>>               allocations) of object allocation. I would like to know your
>>               thoughts and suggestions on this.
>>
>>               I have a detailed proposal on this attached in PDF file.
>>
>>               Thanks,
>>
>>               -Xiaobin
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101215/db110b79/attachment.html 

From y.s.ramakrishna at oracle.com  Wed Dec 15 11:45:38 2010
From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna)
Date: Wed, 15 Dec 2010 11:45:38 -0800
Subject: Trace object allocation flag proposal
In-Reply-To: <AANLkTimtuSFQBW+rrQYp=n-1rr0EinygTmmrpcUMRqN8@mail.gmail.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>	<4D087511.30902@oracle.com>	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>	<4D090388.1040704@oracle.com>	<AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>	<4D091527.2010404@oracle.com>
	<AANLkTimtuSFQBW+rrQYp=n-1rr0EinygTmmrpcUMRqN8@mail.gmail.com>
Message-ID: <4D091AE2.7070901@oracle.com>



On 12/15/10 11:38, Xiaobin Lu wrote:
> Object allocation seems to be a general problem here at least. For many 
> application developers, they think object allocation is cheap. Recently, 
> we uncovered several problems here such as over-allocating StringBuilder 
> object and use StringBuilder(s) with default constructor which leads to 
> constantly array copy and etc.

I absolutely agree.

> 
> Linux system tap is in development stage and not available in early 
> release which is most companies probably use. Surprisingly enough, 
> people are reluctant to move to new platforms, even scare to upgrade 
> their JDK to later version of JDK 6 update release or 64 bit jdk.

I feel your pain :-) (or as John Rose would say "misery loves company").

> 
> I had this hack in my local VM here and I really think we should make it 
> into openjdk so that more people can access that functionality.

Perhaps you can share a webrev so the discussion can become a bit
more concrete as to specific pros-and-cons? I'd suggest upping the
mailing list to hotspot-dev at openjdk.java.net, because I am sure
compiler and GC community folk will also want to look at your webrev/proposal.

-- ramki


From Alan.Bateman at oracle.com  Wed Dec 15 11:53:53 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Dec 2010 19:53:53 +0000
Subject: Trace object allocation flag proposal
In-Reply-To: <AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>	<4D087511.30902@oracle.com>	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>	<4D090388.1040704@oracle.com>
	<AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>
Message-ID: <4D091CD1.1000108@oracle.com>

Xiaobin Lu wrote:
> One of the problems JVMTI has is that once it is enabled, it will fire 
> all kinds of events which will cause even more overheads. Correct me 
> if I am wrong here.
The JVMTI functions and events are partitioned into capabilities and an 
agent enables the capabilities and events that it requires. That said, 
you won't actually find support for object allocation events in the 
spec. Rather it's as Ramki said, JVMTI provides functions to allow 
agents to do load-time or dynamic instrumentation. As the agent is 
inserting java bytecodes then it means the VM can run at "full-speed" 
but it depends on course on what the agent inserts and whether it 
instruments all allocation sites or is selective. Instrumentation can be 
used to observe most object allocation but there are a couple of places 
that aren't easy to instrument such as reflection. For those cases there 
is a VMObjectAlloc event that needs to be enabled.

-Alan.

From tom.rodriguez at oracle.com  Wed Dec 15 12:37:54 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 15 Dec 2010 12:37:54 -0800
Subject: Trace object allocation flag proposal
In-Reply-To: <4D091527.2010404@oracle.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>	<4D087511.30902@oracle.com>	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>	<4D090388.1040704@oracle.com>
	<AANLkTimzUiMNkUFfS2jaC0a+zFezqZA6UZjrPCK2-Lq9@mail.gmail.com>
	<4D091527.2010404@oracle.com>
Message-ID: <752036E7-A79D-4F27-BD53-F96B74FAD9D2@oracle.com>


On Dec 15, 2010, at 11:21 AM, Y. S. Ramakrishna wrote:

> 
> 
> On 12/15/10 10:24, Xiaobin Lu wrote:
>> One of the problems JVMTI has is that once it is enabled, it will fire all kinds of events which will cause even more overheads. Correct me if I am wrong here.
> 
> I didn't think JVMTI is "all or nothing" (if i understood yr statement).
> But i will let the serviceability/JVMTI cognoscenti comment.

We recently fixed a bug that created unneeded overhead in compiled code when running with JVMTI agents.  Previously just the existence of a JVMTI agent turned on some options in the compilers that kept extra locals alive but the fix for 6943485 fixed that.  I think the only compiled overhead you should see these days are when you turn on things like can_post_on_exceptions and can_access_locals.

tom

> 
>> DTrace provides obj-alloc probes which is exactly what many people like to have on Linux. And that is exactly what I am proposing here.
> 
> Ah, i see. (Sorry for not reading through yr proposal before talking.)
> But orthogonally to yr proposal, which is narrowly targeted to addressing
> this specific issue related to object allocation,
> why not use Linux system tap or other to mimic as much as possible the
> Dtrace probes provided by the JVM, rather than making this point fix (if
> i understand yr proposal) for just one aspect of what's offered by
> Dtrace?
> 
> Over to the serviceability folk; and out.
> -- ramki
> 
>> Thanks,
>> -Xiaobin
>> On Wed, Dec 15, 2010 at 10:06 AM, Y. S. Ramakrishna <y.s.ramakrishna at oracle.com <mailto:y.s.ramakrishna at oracle.com>> wrote:
>>    Doesn't JVMTI already provide hooks (BCI?) for tracing allocation?
>>    Perhaps that's found to be too obtrusive? Don't Java IDE's
>>    use JVMTI to already deliver this kind of info to developers?
>>    Pardon my naivette re JVMTI capabilities in this regard.
>>    -- ramki
>>    (java-serviceability-tools-illiterate)
>>    On 12/15/10 10:00, Xiaobin Lu wrote:
>>        Thanks for your feedback, David.
>>        Let me try to clarify with some more background information.
>>        One of the problems many application has is the object
>>        allocation problem (Duh ...). Over releases, GC becomes more and
>>        more frequent. It is pretty hard for one single team to find out
>>        where the problem goes wrong. The existing tool such as jhat or
>>        jmap is very hard to work with giant heap dump file. So the flag
>>        I propose is mostly for diagnostic purpose, it won't be enabled
>>        by default in production. Having said so, if we make it as a
>>        manageable flag, we can turn it on when GC goes wild.
>>        Another value this flag could provide is to find out why
>>        sometime OOM occurs. For example, someone who wrote a search
>>        application on top of Lucene framework suddenly found a crash
>>        due to OOM. The stack trace points to Lucene code which is hard
>>        to instrument, so this flag could provide insight to why the
>>        allocation fails. Maybe it is due to a corrupted length value
>>        passed to "new byte[length];" etc.
>>        I like your idea on per-thread basis, however, for a lot of web
>>        application, thread comes and go. It is pretty hard to pin point
>>        on which thread I want to trace the object allocation.
>>        To answer your last question, what I am really interested in
>>        finding out is what type of object allocation makes GC happens
>>        more frequent. Randomly taking snapshot of heap using jmap is
>>        absolutely not an idea way to do so since not only it generates
>>        a giant file which is difficult to work with, also it will pause
>>        the application and cause negative impact to the application
>>        throughput. After I get the type of hot allocation, if it
>>        happens to be an application level object type such as
>>        com.Xyz.search.IndexReader, I can instrument the constructor to
>>        dump the caller stack. People here also suggests it would be
>>        nice if we could dump the allocation stack trace for some
>>        particular hot types.
>>        I could propose the diff for your folks to review.
>>        Thanks,
>>        -Xiaobin
>>        On Tue, Dec 14, 2010 at 11:58 PM, David Holmes
>>        <David.Holmes at oracle.com <mailto:David.Holmes at oracle.com>
>>        <mailto:David.Holmes at oracle.com
>>        <mailto:David.Holmes at oracle.com>>> wrote:
>>           Hi Xiaobin,
>>           The problem with tracing like this is that to be useful the
>>        tracing
>>           must be unobtrusive and be able to handle getting called
>>        millions of
>>           times (which is what will happen in those GC scenarios you
>>           describe). The sheer volume of data generated as you suggest
>>        below
>>           would overwhelm the app and be pretty hard to work with.
>>           Per-thread statistics of particular types (or of objects
>>        larger than
>>           a certain size) might be more useful, with a dump able to be
>>           requested on-demand.
>>           But I think you'd need to be able to combine this with heap dump
>>           info to be useful.
>>           It really depends on exactly what info you want to be able to
>>           deduce: simple number of objects of given types, hot allocation
>>           sites, hot threads, ...
>>           Cheers,
>>           David
>>           Xiaobin Lu said the following on 12/15/10 17:07:
>>               Hi folks,
>>               I would like to propose a way to trace object allocation on
>>               Linux. On Solaris, we have DTrace which is pretty nice.
>>        But on
>>               Linux, it is almost impossible to do so. Correct me if I am
>>               wrong here.
>>               So I am thinking to add a manageable VM flag and let's
>>        call it
>>               TraceObjectAllocation. When enabled, we can output
>>        something like:
>>               thread id: 10     class name: java/lang/reflect/Method                           size: 80 bytes
>>               thread id: 10     class name: [Ljava/lang/Class;                                  size: 16 bytes
>>               thread id: 10     class name: [C                                                                         size: 56 bytes
>>               thread id: 10     class name: java/lang/reflect/Method                          size: 80 bytes
>>               thread id: 10     class name: [Ljava/lang/Class;                                 size: 16 bytes
>>               As you could imagine, this could be very useful to keep
>>        track of
>>               object allocation behavior in the app. Some smart tool
>>        can take
>>               advantage of this to print a histogram (like top 10 hot
>>               allocations) of object allocation. I would like to know your
>>               thoughts and suggestions on this.
>>               I have a detailed proposal on this attached in PDF file.
>>               Thanks,
>>               -Xiaobin


From stefan.karlsson at oracle.com  Wed Dec 15 08:01:32 2010
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Wed, 15 Dec 2010 16:01:32 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7006659: temporary adlc files are added
	to the build variables
Message-ID: <20101215160135.C4BC8473DD@hg.openjdk.java.net>

Changeset: e7ad5f6f4d29
Author:    stefank
Date:      2010-12-15 05:43 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e7ad5f6f4d29

7006659: temporary adlc files are added to the build variables
Summary: Don't recurse into sub-directories when looking for source files.
Reviewed-by: never, brutisso

! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make
! make/windows/create_obj_files.sh


From David.Holmes at oracle.com  Wed Dec 15 20:47:25 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 16 Dec 2010 14:47:25 +1000
Subject: Trace object allocation flag proposal
In-Reply-To: <AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>	<4D087511.30902@oracle.com>
	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>
Message-ID: <4D0999DD.9020509@oracle.com>

Xiaobin Lu said the following on 12/16/10 04:00:
> Thanks for your feedback, David.
> 
> Let me try to clarify with some more background information.
> 
> One of the problems many application has is the object allocation 
> problem (Duh ...). Over releases, GC becomes more and more frequent. It 
> is pretty hard for one single team to find out where the problem goes 
> wrong. The existing tool such as jhat or jmap is very hard to work with 
> giant heap dump file. So the flag I propose is mostly for diagnostic 
> purpose, it won't be enabled by default in production. Having said so, 
> if we make it as a manageable flag, we can turn it on when GC goes wild.

I don't see this flag as solving the problem. If the heap is filled by a 
millions object allocations then you will have a million trace records 
to process - as difficult as (and less informative than) processing a 
heap dump.

But just by turning on this tracing you will add so much overhead to the 
allocation (potentially) that you will likely completely change the 
allocation pattern and may allow GC to more easily keep up. Any 
mechanism has the potential to do this - even DTrace probes are not as 
unobstrusive as people make out when there are large quantities of 
events occurring. The key to success in these situations is having a 
means to identify the "interesting" events so that you only trace those.

> Another value this flag could provide is to find out why sometime OOM 
> occurs. For example, someone who wrote a search application on top of 
> Lucene framework suddenly found a crash due to OOM. The stack trace 
> points to Lucene code which is hard to instrument, so this flag could 
> provide insight to why the allocation fails. Maybe it is due to a 
> corrupted length value passed to "new byte[length];" etc.

A flag that enables you to track "unusual" allocations would seem of 
more use to detect this kind of condition.


> I like your idea on per-thread basis, however, for a lot of web 
> application, thread comes and go. It is pretty hard to pin point on 
> which thread I want to trace the object allocation.
> 
> To answer your last question, what I am really interested in finding out 
> is what type of object allocation makes GC happens more frequent. 

Most GC's don't know what kind of garbage they are collecting, but I 
wonder if G1 might be of more assistance here?

> Randomly taking snapshot of heap using jmap is absolutely not an idea 
> way to do so since not only it generates a giant file which is difficult 
> to work with, also it will pause the application and cause negative 
> impact to the application throughput. 

So will excessive tracing as per the above. Honestly I think the only 
real way to diagnoze such issue is to let the system get into the 
problematic state, take it offline, take a snapshot and work from that.

I appreciate what you are trying to do, but I don't see this kind of 
tracing as a viable solution.

Cheers,
David
-----

After I get the type of hot
> allocation, if it happens to be an application level object type such as 
> com.Xyz.search.IndexReader, I can instrument the constructor to dump the 
> caller stack. People here also suggests it would be nice if we could 
> dump the allocation stack trace for some particular hot types.
> 
> I could propose the diff for your folks to review.
> 
> Thanks,
> 
> -Xiaobin
> 
> On Tue, Dec 14, 2010 at 11:58 PM, David Holmes <David.Holmes at oracle.com 
> <mailto:David.Holmes at oracle.com>> wrote:
> 
>     Hi Xiaobin,
> 
>     The problem with tracing like this is that to be useful the tracing
>     must be unobtrusive and be able to handle getting called millions of
>     times (which is what will happen in those GC scenarios you
>     describe). The sheer volume of data generated as you suggest below
>     would overwhelm the app and be pretty hard to work with.
> 
>     Per-thread statistics of particular types (or of objects larger than
>     a certain size) might be more useful, with a dump able to be
>     requested on-demand.
> 
>     But I think you'd need to be able to combine this with heap dump
>     info to be useful.
> 
>     It really depends on exactly what info you want to be able to
>     deduce: simple number of objects of given types, hot allocation
>     sites, hot threads, ...
> 
>     Cheers,
>     David
> 
>     Xiaobin Lu said the following on 12/15/10 17:07:
> 
>         Hi folks,
> 
>         I would like to propose a way to trace object allocation on
>         Linux. On Solaris, we have DTrace which is pretty nice. But on
>         Linux, it is almost impossible to do so. Correct me if I am
>         wrong here.
> 
>         So I am thinking to add a manageable VM flag and let's call it
>         TraceObjectAllocation. When enabled, we can output something like:
> 
>         thread id: 10     class name: java/lang/reflect/Method          
>           size: 80 bytes
>         thread id: 10     class name: [Ljava/lang/Class;                
>            size: 16 bytes
>         thread id: 10     class name: [C                                
>                                   size: 56 bytes
>         thread id: 10     class name: java/lang/reflect/Method          
>          size: 80 bytes
>         thread id: 10     class name: [Ljava/lang/Class;                
>           size: 16 bytes
> 
>         As you could imagine, this could be very useful to keep track of
>         object allocation behavior in the app. Some smart tool can take
>         advantage of this to print a histogram (like top 10 hot
>         allocations) of object allocation. I would like to know your
>         thoughts and suggestions on this.
> 
>         I have a detailed proposal on this attached in PDF file.
> 
>         Thanks,
> 
>         -Xiaobin
> 
> 
> 

From jacklusf at gmail.com  Thu Dec 16 11:26:57 2010
From: jacklusf at gmail.com (Xiaobin Lu)
Date: Thu, 16 Dec 2010 11:26:57 -0800
Subject: Trace object allocation flag proposal
In-Reply-To: <4D0999DD.9020509@oracle.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>
	<4D087511.30902@oracle.com>
	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>
	<4D0999DD.9020509@oracle.com>
Message-ID: <AANLkTimsXkenkzQUO-EAUWSQ8WKLCP3wUaqfk+r=0EZ_@mail.gmail.com>

Hi David,

Please see my comments below.

On Wed, Dec 15, 2010 at 8:47 PM, David Holmes <David.Holmes at oracle.com>wrote:

> Xiaobin Lu said the following on 12/16/10 04:00:
>
>  Thanks for your feedback, David.
>>
>> Let me try to clarify with some more background information.
>>
>> One of the problems many application has is the object allocation problem
>> (Duh ...). Over releases, GC becomes more and more frequent. It is pretty
>> hard for one single team to find out where the problem goes wrong. The
>> existing tool such as jhat or jmap is very hard to work with giant heap dump
>> file. So the flag I propose is mostly for diagnostic purpose, it won't be
>> enabled by default in production. Having said so, if we make it as a
>> manageable flag, we can turn it on when GC goes wild.
>>
>
> I don't see this flag as solving the problem. If the heap is filled by a
> millions object allocations then you will have a million trace records to
> process - as difficult as (and less informative than) processing a heap
> dump.
>

The benefit of making this flag as manageable is that we could turn it on /
off when GC becomes abnormal. GC behaviour could be pragmatically figured
out using JMX and then we could use JMX again to turn on that flag. It is
very easy for someone to come up with automation in place to trace the
object allocation on demand.

Having said so, I agree with your statement here. Perhaps we should provide
type filtering so that we won't get as much as records as we could digest.
Your thoughts on this.



>
> But just by turning on this tracing you will add so much overhead to the
> allocation (potentially) that you will likely completely change the
> allocation pattern and may allow GC to more easily keep up. Any mechanism
> has the potential to do this - even DTrace probes are not as unobstrusive as
> people make out when there are large quantities of events occurring. The key
> to success in these situations is having a means to identify the
> "interesting" events so that you only trace those.


The overhead is not as much as we might think, it is just doing printf to
display the allocation type and size. I had this flag turned on with one
workload here and the overhead added is tolerable. I will post more data
here.

The concern of affecting allocation pattern probably should give priority to
have a way to diagnosing the allocation problem. Plus, we don't know how
much impact that will occur to allocation pattern. Or did we ?


>
>
>  Another value this flag could provide is to find out why sometime OOM
>> occurs. For example, someone who wrote a search application on top of Lucene
>> framework suddenly found a crash due to OOM. The stack trace points to
>> Lucene code which is hard to instrument, so this flag could provide insight
>> to why the allocation fails. Maybe it is due to a corrupted length value
>> passed to "new byte[length];" etc.
>>
>
> A flag that enables you to track "unusual" allocations would seem of more
> use to detect this kind of condition.


I could imagine that will be a really hard problem to attack.


>
>
>
>  I like your idea on per-thread basis, however, for a lot of web
>> application, thread comes and go. It is pretty hard to pin point on which
>> thread I want to trace the object allocation.
>>
>> To answer your last question, what I am really interested in finding out
>> is what type of object allocation makes GC happens more frequent.
>>
>
> Most GC's don't know what kind of garbage they are collecting, but I wonder
> if G1 might be of more assistance here?
>
>
>  Randomly taking snapshot of heap using jmap is absolutely not an idea way
>> to do so since not only it generates a giant file which is difficult to work
>> with, also it will pause the application and cause negative impact to the
>> application throughput.
>>
>
> So will excessive tracing as per the above. Honestly I think the only real
> way to diagnoze such issue is to let the system get into the problematic
> state, take it offline, take a snapshot and work from that.
>

Most of time when GC becomes wild, we have to take it offline since we have
no choice. We had one appserver here doing full GC every 1 second. It does
nothing but to collect garbage :-). Having a way to understanding the
allocation is critical to solve this kind of production issue.

Taking snapshot is ok, but analysing the heap is pain of neck. So far, I had
no luck to get jhat to work with 2G heap dump even with -Xmx12g specified
(maybe I should fix that problem instead, John Rose suggested me a while ago
to file a bug, maybe I should work on that problem instead. Sorry for taking
so long.).

Thanks so much for the feedback,

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

From y.s.ramakrishna at oracle.com  Thu Dec 16 12:06:50 2010
From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna)
Date: Thu, 16 Dec 2010 12:06:50 -0800
Subject: Trace object allocation flag proposal
In-Reply-To: <AANLkTimsXkenkzQUO-EAUWSQ8WKLCP3wUaqfk+r=0EZ_@mail.gmail.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>	<4D087511.30902@oracle.com>	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>	<4D0999DD.9020509@oracle.com>
	<AANLkTimsXkenkzQUO-EAUWSQ8WKLCP3wUaqfk+r=0EZ_@mail.gmail.com>
Message-ID: <4D0A715A.1030806@oracle.com>



On 12/16/10 11:26, Xiaobin Lu wrote:
...
> Most of time when GC becomes wild, we have to take it offline since we 
> have no choice. We had one appserver here doing full GC every 1 second. 
> It does nothing but to collect garbage :-). Having a way to 
> understanding the allocation is critical to solve this kind of 
> production issue.

For cases where you end up doing full gc's every second,
I am not sure understanding allocation is as critical. Rather understanding
what caused a leak is probably the issue? (Put another way, in most cases
that i have encountered, GC goes wild not because of unexpectedly high
birth-rates, but because of unexpectedly low death-rates, and at the
risk of sounding morbid, you typically need to investigate the root cause of the
low death-rates, if you know what i mean.)

In any case, if you really need to understand what got allocated,
as David said, that information is there in the snapshot. Those
would be the unexpectedly populous types in your snapshot.

Now what might be useful sometimes is counting at allocation sites,
and may be that was what you were intending? But that usually allows
you to tune optimal performance, rather than catch GC-gone-wild issues.

> 
> Taking snapshot is ok, but analysing the heap is pain of neck. So far, I 
> had no luck to get jhat to work with 2G heap dump even with -Xmx12g 
> specified (maybe I should fix that problem instead, John Rose suggested 
> me a while ago to file a bug, maybe I should work on that problem 
> instead. Sorry for taking so long.).

I have heard of better heap analysis tools than jhat to analyze heap dumps.
I agree that jhat is not easy to use. Besides, in typical cases,
you want to have several dumps and be able to take their "difference" etc
(which is not easy given that object identity is somewhat difficult
unless you calculate a hashcode for each object, which has prohibitively
high scaling costs, and object addresses are meaningless in the presence
of moving GC's).

Fixing bugs in jhat would be a good thing regardless, so go for it :-)

-- ramki

From tomas.hurka at googlemail.com  Fri Dec 17 01:51:50 2010
From: tomas.hurka at googlemail.com (Tomas Hurka)
Date: Fri, 17 Dec 2010 10:51:50 +0100
Subject: Trace object allocation flag proposal
In-Reply-To: <AANLkTimsXkenkzQUO-EAUWSQ8WKLCP3wUaqfk+r=0EZ_@mail.gmail.com>
References: <AANLkTinyVuugdmOO2SDZJqoZq5OYhsp8m+rd_wBJ9KB2@mail.gmail.com>
	<4D087511.30902@oracle.com>
	<AANLkTik4uxHXy-p1eLWDA46yXuenEcdRJV90z4dni6MR@mail.gmail.com>
	<4D0999DD.9020509@oracle.com>
	<AANLkTimsXkenkzQUO-EAUWSQ8WKLCP3wUaqfk+r=0EZ_@mail.gmail.com>
Message-ID: <80F5D527-9B2B-461D-8AAF-EC2C1F49A135@googlemail.com>

Hi Xiaobin,

On 16 Dec 2010, at 20:26, Xiaobin Lu wrote:
[..]
> Taking snapshot is ok, but analysing the heap is pain of neck. So far, I had no luck to get jhat to work with 2G heap dump even with -Xmx12g specified (maybe I should fix that problem instead, John Rose suggested me a while ago to file a bug, maybe I should work on that problem instead. Sorry for taking so long.). 

Instead of jhat you can use Java VisualVM. It does not load the heap dump into memory (it uses memory-mapped files), so it does not need a gigabyte java heap to open 2G heap dump. Try the one from the latest JDK 6u23 and run it on 64bit VM. 

Bye,
--
Tomas Hurka   <mailto:tomas.hurka at oracle.com>
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.dev.java.net
Software Developer
Oracle, Praha Czech Republic


From kevin.walls at oracle.com  Fri Dec 17 14:09:23 2010
From: kevin.walls at oracle.com (kevin.walls at oracle.com)
Date: Fri, 17 Dec 2010 22:09:23 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7003487: clhsdbproc stacktrace fails on
	x64
Message-ID: <20101217220926.874094749D@hg.openjdk.java.net>

Changeset: 6da3527317ff
Author:    kevinw
Date:      2010-12-17 12:14 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6da3527317ff

7003487: clhsdbproc stacktrace fails on x64
Reviewed-by: phh

! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java


From bob.vandette at oracle.com  Mon Dec 20 11:49:16 2010
From: bob.vandette at oracle.com (Bob Vandette)
Date: Mon, 20 Dec 2010 14:49:16 -0500
Subject: Request for Review: 7007769: VM crashes with SIGBUS writing PerfData
	if tmp space is full
Message-ID: <F0BD7087-DDD7-445D-8064-C8F2CB20A103@oracle.com>

New changeset for review.

http://cr.openjdk.java.net/~bobv/7007769

If there is very little /tmp space, the VM will be able to successfully mmap the 
performance data area in /tmp but when the VM attempts to access this memory 
region, it will crash with a SIGBUS if there is insufficient disk space in /tmp.

Solaris will fail the ftruncate call we use to extend the newly created file but Linux does not.
To work around this problem, I write a single byte to each page of the file about to be mmap'd
top reserve the space on the disk.

Bob Vandette
Oracle







From coleen.phillimore at oracle.com  Mon Dec 20 14:11:26 2010
From: coleen.phillimore at oracle.com (coleen phillimore)
Date: Mon, 20 Dec 2010 17:11:26 -0500
Subject: Request for review (and comments) 6302804: Hotspot VM dies ungraceful
	death when C heap is exhausted in various places.
Message-ID: <4D0FD48E.4080009@oracle.com>

Summary: enhance the error reporting mechanism to direct user to fix the 
problem rather than making it look like a VM error.

I changed the error reporting so that out of swap and out of native (C 
heap) memory doesn't look like a VM assert or look like a 
java.lang.OutOfMemoryError exception that someone could catch.  The 
suggested new wording is in the bug link Evaluation section.  I'm open 
to rewording if people have strong preferences.
Also, if solaris runs out of swap space (generally by filling up /tmp), 
access to thread stacks generate a bus error with ENOMEM errno.  I can 
check for this in the solaris signal handler and give the out of C heap 
message.  I couldn't get Linux or windows to fail the same way, so 
didn't apply similar changes there.

open webrev at http://cr.openjdk.java.net/~coleenp/6302804/
bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804

Thanks,
Coleen


From vladimir.kozlov at oracle.com  Mon Dec 20 19:20:51 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 20 Dec 2010 19:20:51 -0800
Subject: Request for review (and comments) 6302804: Hotspot VM dies
	ungraceful death when C heap is exhausted in various places.
In-Reply-To: <4D0FD48E.4080009@oracle.com>
References: <4D0FD48E.4080009@oracle.com>
Message-ID: <4D101D13.4090100@oracle.com>

Coleen,

Could you use "Out of swap space" in "No swap to commit thread stack"?

With these changes next output:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 32764 bytes for ChunkPool::allocate. Out of swap space?
#
#  Internal Error (C:\temp\jprt\P1\B\213124.ap31282\source\src\share\vm\memory\allocation.cpp:181), pid=17396, tid=14008
#  Error: ChunkPool::allocate
#
# JRE version: 7.0
# Java VM: OpenJDK Server VM (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug mixed mode windows-x86 )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Will be converted to next. Right?

# There is insufficient native memory for the Java Runtime Environment to continue.
# Attempting to allocate XXX bytes for mmm. malloc failed.
#
# JRE version: 7.0
# Java VM: OpenJDK Server VM (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug mixed mode windows-x86 )

Could you swap next lines to be consistent with non oom errors?:

  325     if (_id != oom_error) {
  326       st->print_cr("#");

to:

  325     st->print_cr("#");
  326     if (_id != oom_error) {


Instead of next:

# There is insufficient native memory for the Java Runtime Environment to continue.
# Attempting to allocate XXX bytes for mmm. malloc failed.

how about this?:

# There is insufficient native memory for the Java Runtime Environment to continue:
# malloc failed to allocate XXX bytes for mmm.


Also may be add comma at the end of solution lines.
An other solution is to use 64bit VM on 64bit OS.

Thanks,
Vladimir

coleen phillimore wrote:
> Summary: enhance the error reporting mechanism to direct user to fix the 
> problem rather than making it look like a VM error.
> 
> I changed the error reporting so that out of swap and out of native (C 
> heap) memory doesn't look like a VM assert or look like a 
> java.lang.OutOfMemoryError exception that someone could catch.  The 
> suggested new wording is in the bug link Evaluation section.  I'm open 
> to rewording if people have strong preferences.
> Also, if solaris runs out of swap space (generally by filling up /tmp), 
> access to thread stacks generate a bus error with ENOMEM errno.  I can 
> check for this in the solaris signal handler and give the out of C heap 
> message.  I couldn't get Linux or windows to fail the same way, so 
> didn't apply similar changes there.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/6302804/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804
> 
> Thanks,
> Coleen
> 



From forax at univ-mlv.fr  Tue Dec 21 00:18:25 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 21 Dec 2010 09:18:25 +0100
Subject: Request for Review: 7007769: VM crashes with SIGBUS writing
	PerfData if tmp space is full
In-Reply-To: <F0BD7087-DDD7-445D-8064-C8F2CB20A103@oracle.com>
References: <F0BD7087-DDD7-445D-8064-C8F2CB20A103@oracle.com>
Message-ID: <4D1062D1.3040906@univ-mlv.fr>

On 12/20/2010 08:49 PM, Bob Vandette wrote:
> New changeset for review.
>
> http://cr.openjdk.java.net/~bobv/7007769
>
> If there is very little /tmp space, the VM will be able to successfully mmap the
> performance data area in /tmp but when the VM attempts to access this memory
> region, it will crash with a SIGBUS if there is insufficient disk space in /tmp.
>
> Solaris will fail the ftruncate call we use to extend the newly created file but Linux does not.
> To work around this problem, I write a single byte to each page of the file about to be mmap'd
> top reserve the space on the disk.
>
> Bob Vandette
> Oracle
>

Bob,
Linux has a specific mmap option that you can use in this case: 
MAP_POPULATE.

R?mi



From bob.vandette at oracle.com  Tue Dec 21 05:51:04 2010
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 21 Dec 2010 08:51:04 -0500
Subject: Request for Review: 7007769: VM crashes with SIGBUS writing
	PerfData if tmp space is full
In-Reply-To: <4D1062D1.3040906@univ-mlv.fr>
References: <F0BD7087-DDD7-445D-8064-C8F2CB20A103@oracle.com>
	<4D1062D1.3040906@univ-mlv.fr>
Message-ID: <4D10B0C8.6010502@oracle.com>

On 12/21/2010 3:18 AM, R?mi Forax wrote:
> On 12/20/2010 08:49 PM, Bob Vandette wrote:
>> New changeset for review.
>>
>> http://cr.openjdk.java.net/~bobv/7007769
>>
>> If there is very little /tmp space, the VM will be able to 
>> successfully mmap the
>> performance data area in /tmp but when the VM attempts to access this 
>> memory
>> region, it will crash with a SIGBUS if there is insufficient disk 
>> space in /tmp.
>>
>> Solaris will fail the ftruncate call we use to extend the newly 
>> created file but Linux does not.
>> To work around this problem, I write a single byte to each page of 
>> the file about to be mmap'd
>> top reserve the space on the disk.
>>
>> Bob Vandette
>> Oracle
>>
>
> Bob,
> Linux has a specific mmap option that you can use in this case: 
> MAP_POPULATE.
Thanks for looking at my changeset.

I tried that option on my Linux test system and it did not solve my 
problem.  MMAP_POPULATE
is documented to only populate the page tables.  For file mapping it is 
supposed to do a read-ahead
but it doesn't say that it verifies the availability of space for a 
newly created file.

The other two things I didn't like about this option, even if it worked, 
are the fact that this option is
only supported on Linux 2.5.46 and above and that MMAP_POPULATE is only 
supported for private
mappings since 2.6.23.   This fix is for a shared memory region.

Bob.


>
> R?mi
>
>


From joel.franck at oracle.com  Tue Dec 21 08:39:50 2010
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Tue, 21 Dec 2010 17:39:50 +0100
Subject: Request for review (and comments) 6302804: Hotspot VM dies
	ungraceful death when C heap is exhausted in various places.
In-Reply-To: <4D0FD48E.4080009@oracle.com>
References: <4D0FD48E.4080009@oracle.com>
Message-ID: <4D10D856.2050409@oracle.com>

On 12/20/2010 11:11 PM, coleen phillimore wrote:
> Summary: enhance the error reporting mechanism to direct user to fix the
> problem rather than making it look like a VM error.
>
> I changed the error reporting so that out of swap and out of native (C
> heap) memory doesn't look like a VM assert or look like a
> java.lang.OutOfMemoryError exception that someone could catch. The
> suggested new wording is in the bug link Evaluation section. I'm open to
> rewording if people have strong preferences.

Coleen,

I think the proposed wording is good. The message is comprehensible and 
the proposed solutions are sane.

It would be good however if the 4g process hint was included when 
running on 32 bit VMs.

cheers
Joel Borggr?n-Franck
JVM Sustaining Engineering

From forax at univ-mlv.fr  Tue Dec 21 08:57:09 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 21 Dec 2010 17:57:09 +0100
Subject: Request for Review: 7007769: VM crashes with SIGBUS writing
	PerfData if tmp space is full
In-Reply-To: <4D10B0C8.6010502@oracle.com>
References: <F0BD7087-DDD7-445D-8064-C8F2CB20A103@oracle.com>
	<4D1062D1.3040906@univ-mlv.fr> <4D10B0C8.6010502@oracle.com>
Message-ID: <4D10DC65.7020100@univ-mlv.fr>

On 12/21/2010 02:51 PM, Bob Vandette wrote:
> On 12/21/2010 3:18 AM, R?mi Forax wrote:
>> On 12/20/2010 08:49 PM, Bob Vandette wrote:
>>> New changeset for review.
>>>
>>> http://cr.openjdk.java.net/~bobv/7007769
>>>
>>> If there is very little /tmp space, the VM will be able to 
>>> successfully mmap the
>>> performance data area in /tmp but when the VM attempts to access 
>>> this memory
>>> region, it will crash with a SIGBUS if there is insufficient disk 
>>> space in /tmp.
>>>
>>> Solaris will fail the ftruncate call we use to extend the newly 
>>> created file but Linux does not.
>>> To work around this problem, I write a single byte to each page of 
>>> the file about to be mmap'd
>>> top reserve the space on the disk.
>>>
>>> Bob Vandette
>>> Oracle
>>>
>>
>> Bob,
>> Linux has a specific mmap option that you can use in this case: 
>> MAP_POPULATE.
> Thanks for looking at my changeset.
>
> I tried that option on my Linux test system and it did not solve my 
> problem.  MMAP_POPULATE
> is documented to only populate the page tables.  For file mapping it 
> is supposed to do a read-ahead
> but it doesn't say that it verifies the availability of space for a 
> newly created file.

Oups sorry, when I tested it a long time ago, it was working :(

>
> The other two things I didn't like about this option, even if it 
> worked, are the fact that this option is
> only supported on Linux 2.5.46 and above and that MMAP_POPULATE is 
> only supported for private
> mappings since 2.6.23.   This fix is for a shared memory region.
>
> Bob.

R?mi

From bob.vandette at oracle.com  Tue Dec 21 11:35:21 2010
From: bob.vandette at oracle.com (bob.vandette at oracle.com)
Date: Tue, 21 Dec 2010 19:35:21 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7007769: VM crashes with SIGBUS writing
	PerfData if tmp space is full
Message-ID: <20101221193523.6EB6247588@hg.openjdk.java.net>

Changeset: 02895c6a2f82
Author:    bobv
Date:      2010-12-20 14:30 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/02895c6a2f82

7007769: VM crashes with SIGBUS writing PerfData if tmp space is full
Summary: Fill perfdata file with zeros to verify available disk space
Reviewed-by: coleenp, kamg

! src/os/linux/vm/perfMemory_linux.cpp


From daniel.daugherty at oracle.com  Tue Dec 21 15:26:30 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 21 Dec 2010 16:26:30 -0700
Subject: serviceability agent (SA) fix for VS2010 (6987812)
Message-ID: <4D1137A6.1090608@oracle.com>

Greetings,

I would like to get a couple of code reviews for my fix to the
following JDK7/HSX-20 bug:

    6987812 2/3 SAJDI: "gHotSpotVMTypes was not initialized properly in
                the remote process"

Here is the URL for the webrev:

    http://cr.openjdk.java.net/~dcubed/6987812-webrev/0/

Here is an overview of the changes:

- Reorder the code in HotSpotTypeDataBase.readVMTypes() to lookup
  and decode the 'gHotSpotVMTypes' symbol first. This should help
  make any future failures in this area more consistent.

- COFFFileParser changes:
  - add comments to clarify some of the algorithms
  - read 'Base Of Data' field in optional header when PE32
    format COFF file is read
  - change ExportDirectoryTableImpl to return the 'Export RVA' field
    without modification and to return the 'Forwarder RVA' field
    after adjusting the address into a file offset

- update debugger/win32/coff/DumpExports to include more info about
  the section headers and to dump the exported symbol info in a more
  understandable order

- update debugger/win32/coff/TestParser to more clearly access the
  section header using 1-based indices instead of 0-based indices

- update the static initializer in debugger/windbg/WindbgDebuggerLocal
  to use different library loading logic for dbgeng.dll and dbghelp.dll.
  The library pair is searched for in:

   - $JAVA_HOME/jre/bin
   - dir named by DEBUGGINGTOOLSFORWINDOWS environment variable
   - the "Debugging Tools For Windows" program directory
   - the "Debugging Tools For Windows (x86)" program directory
   - the "Debugging Tools For Windows (x64)" program directory
   - the system directory (WINDOWS/system32 is searched last)

- the sawwindb.dll is now explicitly loaded from $JAVA_HOME/jre/bin

Thanks, in advance, for any reviews.

Dan


From David.Holmes at oracle.com  Tue Dec 21 17:08:18 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 22 Dec 2010 11:08:18 +1000
Subject: Request for review (trivial): 7008444 Remove unnecessary include
	of stdint.h in java_md.c
Message-ID: <4D114F82.9070708@oracle.com>

The changes for 7006354 added an include of stdint.h in 
src/os/posix/launcher/java_md.c, but this include file does not exist in 
Solaris 8, which is the build platform for JDK6.

http://cr.openjdk.java.net/~dholmes/7008444/

The change was investigated and implemented by Bengt Rutisson, but as 
he's now on vacation I'm doing the push with Bengt as one reviewer.

Tested via JPRT builds for different release trains.

Thanks,
David Holmes

From vladimir.kozlov at oracle.com  Tue Dec 21 17:19:54 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 21 Dec 2010 17:19:54 -0800
Subject: Request for review (trivial): 7008444 Remove unnecessary include
	of stdint.h in java_md.c
In-Reply-To: <4D114F82.9070708@oracle.com>
References: <4D114F82.9070708@oracle.com>
Message-ID: <4D11523A.3010106@oracle.com>

Looks good. Thank you, David, for catching this before we fork HS20 for 6 update.

Thanks,
Vladimir

David Holmes wrote:
> The changes for 7006354 added an include of stdint.h in 
> src/os/posix/launcher/java_md.c, but this include file does not exist in 
> Solaris 8, which is the build platform for JDK6.
> 
> http://cr.openjdk.java.net/~dholmes/7008444/
> 
> The change was investigated and implemented by Bengt Rutisson, but as 
> he's now on vacation I'm doing the push with Bengt as one reviewer.
> 
> Tested via JPRT builds for different release trains.
> 
> Thanks,
> David Holmes

From david.holmes at oracle.com  Wed Dec 22 01:30:22 2010
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Wed, 22 Dec 2010 09:30:22 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7008444: Remove unnecessary include of
	stdint.h in java_md.c
Message-ID: <20101222093024.84F79475C8@hg.openjdk.java.net>

Changeset: e58d06a8037e
Author:    dholmes
Date:      2010-12-21 23:39 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e58d06a8037e

7008444: Remove unnecessary include of stdint.h in java_md.c
Summary: Remove unnecessary include of stdint.h in java_md.c
Reviewed-by: brutisso, kvn

! src/os/posix/launcher/java_md.c


From daniel.daugherty at oracle.com  Wed Dec 22 08:05:28 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 22 Dec 2010 09:05:28 -0700
Subject: serviceability agent (SA) fix for VS2010 (6987812)
In-Reply-To: <4D1137A6.1090608@oracle.com>
References: <4D1137A6.1090608@oracle.com>
Message-ID: <4D1221C8.5050401@oracle.com>

It occurs to me that some folks might want to look at the spec:

http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
http://kishorekumar.net/pecoff_v8.1.htm

The Microsoft link has a click through agreement so I also provided
a link to a copy of the straight HTML that I found.

Dan


On 12/21/2010 4:26 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> I would like to get a couple of code reviews for my fix to the
> following JDK7/HSX-20 bug:
>
>    6987812 2/3 SAJDI: "gHotSpotVMTypes was not initialized properly in
>                the remote process"
>
> Here is the URL for the webrev:
>
>    http://cr.openjdk.java.net/~dcubed/6987812-webrev/0/
>
> Here is an overview of the changes:
>
> - Reorder the code in HotSpotTypeDataBase.readVMTypes() to lookup
>  and decode the 'gHotSpotVMTypes' symbol first. This should help
>  make any future failures in this area more consistent.
>
> - COFFFileParser changes:
>  - add comments to clarify some of the algorithms
>  - read 'Base Of Data' field in optional header when PE32
>    format COFF file is read
>  - change ExportDirectoryTableImpl to return the 'Export RVA' field
>    without modification and to return the 'Forwarder RVA' field
>    after adjusting the address into a file offset
>
> - update debugger/win32/coff/DumpExports to include more info about
>  the section headers and to dump the exported symbol info in a more
>  understandable order
>
> - update debugger/win32/coff/TestParser to more clearly access the
>  section header using 1-based indices instead of 0-based indices
>
> - update the static initializer in debugger/windbg/WindbgDebuggerLocal
>  to use different library loading logic for dbgeng.dll and dbghelp.dll.
>  The library pair is searched for in:
>
>   - $JAVA_HOME/jre/bin
>   - dir named by DEBUGGINGTOOLSFORWINDOWS environment variable
>   - the "Debugging Tools For Windows" program directory
>   - the "Debugging Tools For Windows (x86)" program directory
>   - the "Debugging Tools For Windows (x64)" program directory
>   - the system directory (WINDOWS/system32 is searched last)
>
> - the sawwindb.dll is now explicitly loaded from $JAVA_HOME/jre/bin
>
> Thanks, in advance, for any reviews.
>
> Dan
>
>

From zhengyu.gu at oracle.com  Wed Dec 22 13:43:51 2010
From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com)
Date: Wed, 22 Dec 2010 21:43:51 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20101222214355.16F594763F@hg.openjdk.java.net>

Changeset: 1e637defdda6
Author:    zgu
Date:      2010-12-22 11:24 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1e637defdda6

6961186: Better VM handling of unexpected exceptions from application native code
Summary: Trap uncaught C++ exception on Windows and Solaris and generate hs_err report.
Reviewed-by: coleenp, bobv, dholmes

! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp

Changeset: c19157304e08
Author:    zgu
Date:      2010-12-22 11:52 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c19157304e08

Merge

! src/os/windows/vm/os_windows.cpp


From daniel.daugherty at oracle.com  Wed Dec 22 14:46:47 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 22 Dec 2010 15:46:47 -0700
Subject: SECOND CALL: serviceability agent (SA) fix for VS2010 (6987812)
In-Reply-To: <4D1221C8.5050401@oracle.com>
References: <4D1137A6.1090608@oracle.com> <4D1221C8.5050401@oracle.com>
Message-ID: <4D127FD7.5070109@oracle.com>

Second Call!

I'm trying to get this fix in before the holiday break.
This should take < 15 minutes unless you try reading the
Microsoft spec.... :-)

Dan



On 12/22/2010 9:05 AM, Daniel D. Daugherty wrote:
> It occurs to me that some folks might want to look at the spec:
>
> http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
> http://kishorekumar.net/pecoff_v8.1.htm
>
> The Microsoft link has a click through agreement so I also provided
> a link to a copy of the straight HTML that I found.
>
> Dan
>
>
> On 12/21/2010 4:26 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I would like to get a couple of code reviews for my fix to the
>> following JDK7/HSX-20 bug:
>>
>>    6987812 2/3 SAJDI: "gHotSpotVMTypes was not initialized properly in
>>                the remote process"
>>
>> Here is the URL for the webrev:
>>
>>    http://cr.openjdk.java.net/~dcubed/6987812-webrev/0/
>>
>> Here is an overview of the changes:
>>
>> - Reorder the code in HotSpotTypeDataBase.readVMTypes() to lookup
>>  and decode the 'gHotSpotVMTypes' symbol first. This should help
>>  make any future failures in this area more consistent.
>>
>> - COFFFileParser changes:
>>  - add comments to clarify some of the algorithms
>>  - read 'Base Of Data' field in optional header when PE32
>>    format COFF file is read
>>  - change ExportDirectoryTableImpl to return the 'Export RVA' field
>>    without modification and to return the 'Forwarder RVA' field
>>    after adjusting the address into a file offset
>>
>> - update debugger/win32/coff/DumpExports to include more info about
>>  the section headers and to dump the exported symbol info in a more
>>  understandable order
>>
>> - update debugger/win32/coff/TestParser to more clearly access the
>>  section header using 1-based indices instead of 0-based indices
>>
>> - update the static initializer in debugger/windbg/WindbgDebuggerLocal
>>  to use different library loading logic for dbgeng.dll and dbghelp.dll.
>>  The library pair is searched for in:
>>
>>   - $JAVA_HOME/jre/bin
>>   - dir named by DEBUGGINGTOOLSFORWINDOWS environment variable
>>   - the "Debugging Tools For Windows" program directory
>>   - the "Debugging Tools For Windows (x86)" program directory
>>   - the "Debugging Tools For Windows (x64)" program directory
>>   - the system directory (WINDOWS/system32 is searched last)
>>
>> - the sawwindb.dll is now explicitly loaded from $JAVA_HOME/jre/bin
>>
>> Thanks, in advance, for any reviews.
>>
>> Dan
>>
>>
>

From daniel.daugherty at oracle.com  Wed Dec 22 15:15:11 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 22 Dec 2010 16:15:11 -0700
Subject: SECOND CALL: serviceability agent (SA) fix for VS2010 (6987812)
In-Reply-To: <4D1281AD.8030501@oracle.com>
References: <4D1137A6.1090608@oracle.com> <4D1221C8.5050401@oracle.com>
	<4D127FD7.5070109@oracle.com> <4D1281AD.8030501@oracle.com>
Message-ID: <4D12867F.2030506@oracle.com>

Added original reviewer list back in since this is an open review...

Thanks for the review!

Dan


On 12/22/2010 3:54 PM, Swamy Venkataramanappa wrote:
> Dan,
>
> I did a quick review of your code and it looks good.
> I did not read Microsoft spec.
>
> Thanks,
> -Swamy
>
> On 12/22/2010 4:46 PM, Daniel D. Daugherty wrote:
>> Second Call!
>>
>> I'm trying to get this fix in before the holiday break.
>> This should take < 15 minutes unless you try reading the
>> Microsoft spec.... :-)
>>
>> Dan
>>
>>
>>
>> On 12/22/2010 9:05 AM, Daniel D. Daugherty wrote:
>>> It occurs to me that some folks might want to look at the spec:
>>>
>>> http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
>>> http://kishorekumar.net/pecoff_v8.1.htm
>>>
>>> The Microsoft link has a click through agreement so I also provided
>>> a link to a copy of the straight HTML that I found.
>>>
>>> Dan
>>>
>>>
>>> On 12/21/2010 4:26 PM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> I would like to get a couple of code reviews for my fix to the
>>>> following JDK7/HSX-20 bug:
>>>>
>>>>    6987812 2/3 SAJDI: "gHotSpotVMTypes was not initialized properly in
>>>>                the remote process"
>>>>
>>>> Here is the URL for the webrev:
>>>>
>>>>    http://cr.openjdk.java.net/~dcubed/6987812-webrev/0/
>>>>
>>>> Here is an overview of the changes:
>>>>
>>>> - Reorder the code in HotSpotTypeDataBase.readVMTypes() to lookup
>>>>  and decode the 'gHotSpotVMTypes' symbol first. This should help
>>>>  make any future failures in this area more consistent.
>>>>
>>>> - COFFFileParser changes:
>>>>  - add comments to clarify some of the algorithms
>>>>  - read 'Base Of Data' field in optional header when PE32
>>>>    format COFF file is read
>>>>  - change ExportDirectoryTableImpl to return the 'Export RVA' field
>>>>    without modification and to return the 'Forwarder RVA' field
>>>>    after adjusting the address into a file offset
>>>>
>>>> - update debugger/win32/coff/DumpExports to include more info about
>>>>  the section headers and to dump the exported symbol info in a more
>>>>  understandable order
>>>>
>>>> - update debugger/win32/coff/TestParser to more clearly access the
>>>>  section header using 1-based indices instead of 0-based indices
>>>>
>>>> - update the static initializer in debugger/windbg/WindbgDebuggerLocal
>>>>  to use different library loading logic for dbgeng.dll and 
>>>> dbghelp.dll.
>>>>  The library pair is searched for in:
>>>>
>>>>   - $JAVA_HOME/jre/bin
>>>>   - dir named by DEBUGGINGTOOLSFORWINDOWS environment variable
>>>>   - the "Debugging Tools For Windows" program directory
>>>>   - the "Debugging Tools For Windows (x86)" program directory
>>>>   - the "Debugging Tools For Windows (x64)" program directory
>>>>   - the system directory (WINDOWS/system32 is searched last)
>>>>
>>>> - the sawwindb.dll is now explicitly loaded from $JAVA_HOME/jre/bin
>>>>
>>>> Thanks, in advance, for any reviews.
>>>>
>>>> Dan
>>>>
>>>>
>>>

From vladimir.kozlov at oracle.com  Wed Dec 22 15:20:02 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 22 Dec 2010 15:20:02 -0800
Subject: Request for review (and comments) 6302804: Hotspot VM dies
	ungraceful death when C heap is exhausted in various places.
In-Reply-To: <4D101D13.4090100@oracle.com>
References: <4D0FD48E.4080009@oracle.com> <4D101D13.4090100@oracle.com>
Message-ID: <4D1287A2.6060006@oracle.com>

Coleen,

Could you also fix "JRE version: 7.0" output to print full JRE version (as with -version) since you are touching this code?

Thanks,
Vladimir

Vladimir Kozlov wrote:
> Coleen,
> 
> Could you use "Out of swap space" in "No swap to commit thread stack"?
> 
> With these changes next output:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # java.lang.OutOfMemoryError: requested 32764 bytes for 
> ChunkPool::allocate. Out of swap space?
> #
> #  Internal Error 
> (C:\temp\jprt\P1\B\213124.ap31282\source\src\share\vm\memory\allocation.cpp:181), 
> pid=17396, tid=14008
> #  Error: ChunkPool::allocate
> #
> # JRE version: 7.0
> # Java VM: OpenJDK Server VM 
> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug mixed 
> mode windows-x86 )
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> 
> Will be converted to next. Right?
> 
> # There is insufficient native memory for the Java Runtime Environment 
> to continue.
> # Attempting to allocate XXX bytes for mmm. malloc failed.
> #
> # JRE version: 7.0
> # Java VM: OpenJDK Server VM 
> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug mixed 
> mode windows-x86 )
> 
> Could you swap next lines to be consistent with non oom errors?:
> 
>  325     if (_id != oom_error) {
>  326       st->print_cr("#");
> 
> to:
> 
>  325     st->print_cr("#");
>  326     if (_id != oom_error) {
> 
> 
> Instead of next:
> 
> # There is insufficient native memory for the Java Runtime Environment 
> to continue.
> # Attempting to allocate XXX bytes for mmm. malloc failed.
> 
> how about this?:
> 
> # There is insufficient native memory for the Java Runtime Environment 
> to continue:
> # malloc failed to allocate XXX bytes for mmm.
> 
> 
> Also may be add comma at the end of solution lines.
> An other solution is to use 64bit VM on 64bit OS.
> 
> Thanks,
> Vladimir
> 
> coleen phillimore wrote:
>> Summary: enhance the error reporting mechanism to direct user to fix 
>> the problem rather than making it look like a VM error.
>>
>> I changed the error reporting so that out of swap and out of native (C 
>> heap) memory doesn't look like a VM assert or look like a 
>> java.lang.OutOfMemoryError exception that someone could catch.  The 
>> suggested new wording is in the bug link Evaluation section.  I'm open 
>> to rewording if people have strong preferences.
>> Also, if solaris runs out of swap space (generally by filling up 
>> /tmp), access to thread stacks generate a bus error with ENOMEM 
>> errno.  I can check for this in the solaris signal handler and give 
>> the out of C heap message.  I couldn't get Linux or windows to fail 
>> the same way, so didn't apply similar changes there.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6302804/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804
>>
>> Thanks,
>> Coleen
>>
> 
> 

From coleen.phillimore at oracle.com  Wed Dec 22 15:54:40 2010
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 22 Dec 2010 18:54:40 -0500
Subject: Request for review (and comments) 6302804: Hotspot VM dies
	ungraceful death when C heap is exhausted in various places.
In-Reply-To: <4D1287A2.6060006@oracle.com>
References: <4D0FD48E.4080009@oracle.com> <4D101D13.4090100@oracle.com>
	<4D1287A2.6060006@oracle.com>
Message-ID: <4D128FC0.9050306@oracle.com>

On 12/22/2010 6:20 PM, Vladimir Kozlov wrote:
> Coleen,
>
> Could you also fix "JRE version: 7.0" output to print full JRE version 
> (as with -version) since you are touching this code?
Actually, I tried to do this when I implemented this the first time.  If 
I remember correctly, most of the text from -version comes from the JDK 
and the only bit of the version I could find from the VM was in 
vm_version(), which was just this number.  Because it was in error 
handling, I didn't want to add a callback to the jdk (or call one if it 
already existed).

Coleen
>
> Thanks,
> Vladimir
>
> Vladimir Kozlov wrote:
>> Coleen,
>>
>> Could you use "Out of swap space" in "No swap to commit thread stack"?
>>
>> With these changes next output:
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # java.lang.OutOfMemoryError: requested 32764 bytes for 
>> ChunkPool::allocate. Out of swap space?
>> #
>> #  Internal Error 
>> (C:\temp\jprt\P1\B\213124.ap31282\source\src\share\vm\memory\allocation.cpp:181), 
>> pid=17396, tid=14008
>> #  Error: ChunkPool::allocate
>> #
>> # JRE version: 7.0
>> # Java VM: OpenJDK Server VM 
>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>> mixed mode windows-x86 )
>> # If you would like to submit a bug report, please visit:
>> #   http://java.sun.com/webapps/bugreport/crash.jsp
>> #
>>
>> Will be converted to next. Right?
>>
>> # There is insufficient native memory for the Java Runtime 
>> Environment to continue.
>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>> #
>> # JRE version: 7.0
>> # Java VM: OpenJDK Server VM 
>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>> mixed mode windows-x86 )
>>
>> Could you swap next lines to be consistent with non oom errors?:
>>
>>  325     if (_id != oom_error) {
>>  326       st->print_cr("#");
>>
>> to:
>>
>>  325     st->print_cr("#");
>>  326     if (_id != oom_error) {
>>
>>
>> Instead of next:
>>
>> # There is insufficient native memory for the Java Runtime 
>> Environment to continue.
>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>>
>> how about this?:
>>
>> # There is insufficient native memory for the Java Runtime 
>> Environment to continue:
>> # malloc failed to allocate XXX bytes for mmm.
>>
>>
>> Also may be add comma at the end of solution lines.
>> An other solution is to use 64bit VM on 64bit OS.
>>
>> Thanks,
>> Vladimir
>>
>> coleen phillimore wrote:
>>> Summary: enhance the error reporting mechanism to direct user to fix 
>>> the problem rather than making it look like a VM error.
>>>
>>> I changed the error reporting so that out of swap and out of native 
>>> (C heap) memory doesn't look like a VM assert or look like a 
>>> java.lang.OutOfMemoryError exception that someone could catch.  The 
>>> suggested new wording is in the bug link Evaluation section.  I'm 
>>> open to rewording if people have strong preferences.
>>> Also, if solaris runs out of swap space (generally by filling up 
>>> /tmp), access to thread stacks generate a bus error with ENOMEM 
>>> errno.  I can check for this in the solaris signal handler and give 
>>> the out of C heap message.  I couldn't get Linux or windows to fail 
>>> the same way, so didn't apply similar changes there.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/6302804/
>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804
>>>
>>> Thanks,
>>> Coleen
>>>
>>
>>


From vladimir.kozlov at oracle.com  Wed Dec 22 16:44:40 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 22 Dec 2010 16:44:40 -0800
Subject: Request for review (and comments) 6302804: Hotspot VM dies
	ungraceful death when C heap is exhausted in various places.
In-Reply-To: <4D128FC0.9050306@oracle.com>
References: <4D0FD48E.4080009@oracle.com> <4D101D13.4090100@oracle.com>
	<4D1287A2.6060006@oracle.com> <4D128FC0.9050306@oracle.com>
Message-ID: <4D129B78.20505@oracle.com>

Sorry for noise - it was JDK bug.

I found that the problem was with previous JDK with build > 99:
6994413: JDK_GetVersionInfo0 only expects a two digit build number

This bug was fixed in b118 JDK.

So when we used before jdk7-b107 for JPRT it had this bug.

Latest JPRT builds (which uses latest jdk) does not have this problem:

# JRE version: 7.0-b122
# Java VM: OpenJDK 64-Bit Server VM (20.0-b04-internal-201012221004.ct232829.7007377-fastdebug compiled mode solaris-sparc compressed oops)

Thanks,
Vladimir


Coleen Phillimore wrote:
> On 12/22/2010 6:20 PM, Vladimir Kozlov wrote:
>> Coleen,
>>
>> Could you also fix "JRE version: 7.0" output to print full JRE version 
>> (as with -version) since you are touching this code?
> Actually, I tried to do this when I implemented this the first time.  If 
> I remember correctly, most of the text from -version comes from the JDK 
> and the only bit of the version I could find from the VM was in 
> vm_version(), which was just this number.  Because it was in error 
> handling, I didn't want to add a callback to the jdk (or call one if it 
> already existed).
> 
> Coleen
>>
>> Thanks,
>> Vladimir
>>
>> Vladimir Kozlov wrote:
>>> Coleen,
>>>
>>> Could you use "Out of swap space" in "No swap to commit thread stack"?
>>>
>>> With these changes next output:
>>>
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> # java.lang.OutOfMemoryError: requested 32764 bytes for 
>>> ChunkPool::allocate. Out of swap space?
>>> #
>>> #  Internal Error 
>>> (C:\temp\jprt\P1\B\213124.ap31282\source\src\share\vm\memory\allocation.cpp:181), 
>>> pid=17396, tid=14008
>>> #  Error: ChunkPool::allocate
>>> #
>>> # JRE version: 7.0
>>> # Java VM: OpenJDK Server VM 
>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>>> mixed mode windows-x86 )
>>> # If you would like to submit a bug report, please visit:
>>> #   http://java.sun.com/webapps/bugreport/crash.jsp
>>> #
>>>
>>> Will be converted to next. Right?
>>>
>>> # There is insufficient native memory for the Java Runtime 
>>> Environment to continue.
>>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>>> #
>>> # JRE version: 7.0
>>> # Java VM: OpenJDK Server VM 
>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>>> mixed mode windows-x86 )
>>>
>>> Could you swap next lines to be consistent with non oom errors?:
>>>
>>>  325     if (_id != oom_error) {
>>>  326       st->print_cr("#");
>>>
>>> to:
>>>
>>>  325     st->print_cr("#");
>>>  326     if (_id != oom_error) {
>>>
>>>
>>> Instead of next:
>>>
>>> # There is insufficient native memory for the Java Runtime 
>>> Environment to continue.
>>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>>>
>>> how about this?:
>>>
>>> # There is insufficient native memory for the Java Runtime 
>>> Environment to continue:
>>> # malloc failed to allocate XXX bytes for mmm.
>>>
>>>
>>> Also may be add comma at the end of solution lines.
>>> An other solution is to use 64bit VM on 64bit OS.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> coleen phillimore wrote:
>>>> Summary: enhance the error reporting mechanism to direct user to fix 
>>>> the problem rather than making it look like a VM error.
>>>>
>>>> I changed the error reporting so that out of swap and out of native 
>>>> (C heap) memory doesn't look like a VM assert or look like a 
>>>> java.lang.OutOfMemoryError exception that someone could catch.  The 
>>>> suggested new wording is in the bug link Evaluation section.  I'm 
>>>> open to rewording if people have strong preferences.
>>>> Also, if solaris runs out of swap space (generally by filling up 
>>>> /tmp), access to thread stacks generate a bus error with ENOMEM 
>>>> errno.  I can check for this in the solaris signal handler and give 
>>>> the out of C heap message.  I couldn't get Linux or windows to fail 
>>>> the same way, so didn't apply similar changes there.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6302804/
>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>
>>>
> 

From poonam.bajaj at oracle.com  Wed Dec 22 17:17:41 2010
From: poonam.bajaj at oracle.com (Poonam Bajaj)
Date: Thu, 23 Dec 2010 06:47:41 +0530
Subject: SECOND CALL: serviceability agent (SA) fix for VS2010 (6987812)
In-Reply-To: <4D12867F.2030506@oracle.com>
References: <4D1137A6.1090608@oracle.com> <4D1221C8.5050401@oracle.com>
	<4D127FD7.5070109@oracle.com> <4D1281AD.8030501@oracle.com>
	<4D12867F.2030506@oracle.com>
Message-ID: <4D12A335.20804@oracle.com>

Hi Dan,

I looked at the changes. It looks good. Thanks for fixing the search 
logic for dbg*.dll files in WindbgDebuggerLocal.java.

Thanks,
Poonam

On 12/23/2010 4:45 AM, Daniel D. Daugherty wrote:
> Added original reviewer list back in since this is an open review...
>
> Thanks for the review!
>
> Dan
>
>
> On 12/22/2010 3:54 PM, Swamy Venkataramanappa wrote:
>> Dan,
>>
>> I did a quick review of your code and it looks good.
>> I did not read Microsoft spec.
>>
>> Thanks,
>> -Swamy
>>
>> On 12/22/2010 4:46 PM, Daniel D. Daugherty wrote:
>>> Second Call!
>>>
>>> I'm trying to get this fix in before the holiday break.
>>> This should take < 15 minutes unless you try reading the
>>> Microsoft spec.... :-)
>>>
>>> Dan
>>>
>>>
>>>
>>> On 12/22/2010 9:05 AM, Daniel D. Daugherty wrote:
>>>> It occurs to me that some folks might want to look at the spec:
>>>>
>>>> http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
>>>> http://kishorekumar.net/pecoff_v8.1.htm
>>>>
>>>> The Microsoft link has a click through agreement so I also provided
>>>> a link to a copy of the straight HTML that I found.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 12/21/2010 4:26 PM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> I would like to get a couple of code reviews for my fix to the
>>>>> following JDK7/HSX-20 bug:
>>>>>
>>>>>    6987812 2/3 SAJDI: "gHotSpotVMTypes was not initialized 
>>>>> properly in
>>>>>                the remote process"
>>>>>
>>>>> Here is the URL for the webrev:
>>>>>
>>>>>    http://cr.openjdk.java.net/~dcubed/6987812-webrev/0/
>>>>>
>>>>> Here is an overview of the changes:
>>>>>
>>>>> - Reorder the code in HotSpotTypeDataBase.readVMTypes() to lookup
>>>>>  and decode the 'gHotSpotVMTypes' symbol first. This should help
>>>>>  make any future failures in this area more consistent.
>>>>>
>>>>> - COFFFileParser changes:
>>>>>  - add comments to clarify some of the algorithms
>>>>>  - read 'Base Of Data' field in optional header when PE32
>>>>>    format COFF file is read
>>>>>  - change ExportDirectoryTableImpl to return the 'Export RVA' field
>>>>>    without modification and to return the 'Forwarder RVA' field
>>>>>    after adjusting the address into a file offset
>>>>>
>>>>> - update debugger/win32/coff/DumpExports to include more info about
>>>>>  the section headers and to dump the exported symbol info in a more
>>>>>  understandable order
>>>>>
>>>>> - update debugger/win32/coff/TestParser to more clearly access the
>>>>>  section header using 1-based indices instead of 0-based indices
>>>>>
>>>>> - update the static initializer in 
>>>>> debugger/windbg/WindbgDebuggerLocal
>>>>>  to use different library loading logic for dbgeng.dll and 
>>>>> dbghelp.dll.
>>>>>  The library pair is searched for in:
>>>>>
>>>>>   - $JAVA_HOME/jre/bin
>>>>>   - dir named by DEBUGGINGTOOLSFORWINDOWS environment variable
>>>>>   - the "Debugging Tools For Windows" program directory
>>>>>   - the "Debugging Tools For Windows (x86)" program directory
>>>>>   - the "Debugging Tools For Windows (x64)" program directory
>>>>>   - the system directory (WINDOWS/system32 is searched last)
>>>>>
>>>>> - the sawwindb.dll is now explicitly loaded from $JAVA_HOME/jre/bin
>>>>>
>>>>> Thanks, in advance, for any reviews.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>

From coleen.phillimore at oracle.com  Wed Dec 22 18:34:26 2010
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 23 Dec 2010 02:34:26 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 29 new changesets
Message-ID: <20101223023518.AA35C47659@hg.openjdk.java.net>

Changeset: 5fa559508216
Author:    iveresov
Date:      2010-12-15 20:43 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5fa559508216

7007229: Fix warnings with VS2010 in compressedStream.cpp
Summary: An interference between a fix for 6993125 and disabled optimization in compressedStream.cpp produces a warning with VS2010. Disable the warning for the code fragment for which the optimizations are disabled.
Reviewed-by: kvn

! src/share/vm/code/compressedStream.cpp

Changeset: f2da85a9b08e
Author:    twisti
Date:      2010-11-30 09:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f2da85a9b08e

7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM
Summary: Because of the removal of language support, the JDK 7 API for JSR 292 no longer includes a public class named java/dyn/InvokeDynamic.
Reviewed-by: jrose, kvn

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/thread.cpp

Changeset: ac637b7220d1
Author:    iveresov
Date:      2010-11-30 23:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ac637b7220d1

6985015: C1 needs to support compressed oops
Summary: This change implements compressed oops for C1 for x64 and sparc. The changes are mostly on the codegen level, with a few exceptions when we do access things outside of the heap that are uncompressed from the IR. Compressed oops are now also enabled with tiered.
Reviewed-by: twisti, kvn, never, phh

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_Defs_x86.hpp
! src/cpu/x86/vm/c1_FrameMap_x86.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_LinearScan_x86.hpp
! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: dbbf44db0107
Author:    iveresov
Date:      2010-11-30 23:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/dbbf44db0107

Merge


Changeset: 4da76e32c0be
Author:    never
Date:      2010-12-01 10:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4da76e32c0be

7002666: eclipse CDT projects crash with compressed oops
Reviewed-by: kvn, twisti

! src/share/vm/opto/memnode.cpp
+ test/compiler/7002666/Test7002666.java

Changeset: 0cb042fd2d4b
Author:    never
Date:      2010-12-01 15:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0cb042fd2d4b

6875026: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LinearScan.cpp:5486
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp

Changeset: bbefa3ca1543
Author:    twisti
Date:      2010-12-02 01:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bbefa3ca1543

6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten with oop
Reviewed-by: kvn, never

! src/cpu/x86/vm/stubGenerator_x86_64.cpp

Changeset: 5ddfcf4b079e
Author:    iveresov
Date:      2010-12-02 17:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5ddfcf4b079e

7003554: (tiered) assert(is_null_object() || handle() != NULL) failed: cannot embed null pointer
Summary: C1 with profiling doesn't check whether the MDO has been really allocated, which can silently fail if the perm gen is full. The solution is to check if the allocation failed and bailout out of inlining or compilation.
Reviewed-by: kvn, never

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/graphKit.cpp

Changeset: 2f644f85485d
Author:    twisti
Date:      2010-12-03 01:34 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2f644f85485d

6961690: load oops from constant table on SPARC
Summary: oops should be loaded from the constant table of an nmethod instead of materializing them with a long code sequence.
Reviewed-by: never, kvn

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vm_version_sparc.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/os/linux/vm/vmError_linux.cpp
! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/adlparse.hpp
! src/share/vm/adlc/archDesc.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/assembler.inline.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/machnode.hpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/utilities/debug.cpp

Changeset: b856cd7f4e60
Author:    twisti
Date:      2010-12-03 06:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b856cd7f4e60

7003798: test/compiler/6991596 fails with true != false
Summary: The test of 6991596 fails on SPARCV9.
Reviewed-by: kvn, never, jrose

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! test/compiler/6991596/Test6991596.java

Changeset: 7601ab0e1e33
Author:    never
Date:      2010-12-03 12:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7601ab0e1e33

7004530: casx used for 32 bit cas after 7003554
Reviewed-by: kvn, iveresov

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp

Changeset: dad31fc330cd
Author:    jrose
Date:      2010-12-03 15:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/dad31fc330cd

7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute
Reviewed-by: twisti

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/constantPoolOop.hpp
! src/share/vm/prims/jvm.h
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/constantTag.cpp
! src/share/vm/utilities/constantTag.hpp

Changeset: 5fe0781a8560
Author:    kvn
Date:      2010-12-07 11:00 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5fe0781a8560

7004925: CTW: assert(nbits == 32 || -(1 << nbits-1) <= x && x < ( 1 << nbits-1)) failed: value out of range
Summary: Set offset in register if it does not fit 13 bits.
Reviewed-by: iveresov

! src/cpu/sparc/vm/sparc.ad

Changeset: ec8c74742417
Author:    iveresov
Date:      2010-12-08 02:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ec8c74742417

7005241: C1: SEGV in java.util.concurrent.LinkedTransferQueue.xfer() with compressed oops
Summary: Implementation of the CAS primitive for x64 compressed oops was incorrect. It kills rscratch2 register (r11), which is allocatable in C1. Also, we don't need to restore cmpval as it's never used after that, so we need only one temporary register, which can be scratch1.
Reviewed-by: kvn, never

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: 4de5f4101cfd
Author:    iveresov
Date:      2010-12-08 17:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4de5f4101cfd

Merge

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/runtime/thread.cpp

Changeset: 79d8657be916
Author:    kvn
Date:      2010-12-10 14:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/79d8657be916

6993125: runThese crashes with assert(Thread::current()->on_local_stack((address)this))
Summary: add another ResourceObj debug field to distinguish garbage
Reviewed-by: dholmes, coleenp

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp

Changeset: 361783318e7e
Author:    never
Date:      2010-12-13 22:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/361783318e7e

7004940: CTW: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG
Reviewed-by: kvn, twisti

! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/reg_split.cpp

Changeset: f9c511aae070
Author:    iveresov
Date:      2010-12-15 23:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f9c511aae070

Merge


Changeset: 6ce496c8fc07
Author:    coleenp
Date:      2010-12-16 09:31 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6ce496c8fc07

Merge


Changeset: fb712ff22571
Author:    tonyp
Date:      2010-12-14 16:19 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fb712ff22571

7000559: G1: assertion failure !outer || (full_collections_started == _full_collections_completed + 1)
Summary: The concurrent marking thread can complete its operation and increment the full GC counter during a Full GC. This causes the nesting of increments to the start and end of Full GCs that we are expecting to be wrong. the fix is for the marking thread to join the suspendible thread set before incrementing the counter so that it's blocked until the Full GC (or any other safepoint) is finished. The change also includes some minor code cleanup (I renamed a parameter).
Reviewed-by: brutisso, ysr

! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp

Changeset: 36eef023306f
Author:    ysr
Date:      2010-12-16 09:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/36eef023306f

Merge


Changeset: 320ef6401fce
Author:    ysr
Date:      2010-12-16 12:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/320ef6401fce

Merge


Changeset: 03e1b9fce89d
Author:    dholmes
Date:      2010-12-16 20:57 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/03e1b9fce89d

7003707: need to remove (some) system include files from the HotSpot header files
Summary: move socket_available into os_linux.cpp to avoid inclusion of ioctl.h in os_linux.inline.hpp
Reviewed-by: coleenp, stefank, ikrylov

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.inline.hpp

Changeset: 1132ed4a0086
Author:    cl
Date:      2010-12-16 18:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1132ed4a0086

Added tag jdk7-b122 for changeset 3a548dc9cb45

! .hgtags

Changeset: 81fc264cf826
Author:    trims
Date:      2010-12-16 20:32 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/81fc264cf826

Merge

! .hgtags

Changeset: af96d06cc0da
Author:    trims
Date:      2010-12-16 20:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/af96d06cc0da

Merge


Changeset: 9669f9b28410
Author:    trims
Date:      2010-12-16 20:48 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9669f9b28410

Merge


Changeset: 3da13a976363
Author:    coleenp
Date:      2010-12-22 12:24 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3da13a976363

Merge

! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java

Changeset: 07c62ff47437
Author:    coleenp
Date:      2010-12-22 16:52 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/07c62ff47437

Merge



From daniel.daugherty at oracle.com  Wed Dec 22 20:39:00 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 22 Dec 2010 21:39:00 -0700
Subject: SECOND CALL: serviceability agent (SA) fix for VS2010 (6987812)
In-Reply-To: <4D12A335.20804@oracle.com>
References: <4D1137A6.1090608@oracle.com> <4D1221C8.5050401@oracle.com>
	<4D127FD7.5070109@oracle.com> <4D1281AD.8030501@oracle.com>
	<4D12867F.2030506@oracle.com> <4D12A335.20804@oracle.com>
Message-ID: <4D12D264.90104@oracle.com>

Poonam,

Thanks for the review!  And you're most welcome for the lib search logic.

Dan


On 12/22/2010 6:17 PM, Poonam Bajaj wrote:
> Hi Dan,
>
> I looked at the changes. It looks good. Thanks for fixing the search 
> logic for dbg*.dll files in WindbgDebuggerLocal.java.
>
> Thanks,
> Poonam
>
> On 12/23/2010 4:45 AM, Daniel D. Daugherty wrote:
>> Added original reviewer list back in since this is an open review...
>>
>> Thanks for the review!
>>
>> Dan
>>
>>
>> On 12/22/2010 3:54 PM, Swamy Venkataramanappa wrote:
>>> Dan,
>>>
>>> I did a quick review of your code and it looks good.
>>> I did not read Microsoft spec.
>>>
>>> Thanks,
>>> -Swamy
>>>
>>> On 12/22/2010 4:46 PM, Daniel D. Daugherty wrote:
>>>> Second Call!
>>>>
>>>> I'm trying to get this fix in before the holiday break.
>>>> This should take < 15 minutes unless you try reading the
>>>> Microsoft spec.... :-)
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> On 12/22/2010 9:05 AM, Daniel D. Daugherty wrote:
>>>>> It occurs to me that some folks might want to look at the spec:
>>>>>
>>>>> http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
>>>>> http://kishorekumar.net/pecoff_v8.1.htm
>>>>>
>>>>> The Microsoft link has a click through agreement so I also provided
>>>>> a link to a copy of the straight HTML that I found.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 12/21/2010 4:26 PM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> I would like to get a couple of code reviews for my fix to the
>>>>>> following JDK7/HSX-20 bug:
>>>>>>
>>>>>>    6987812 2/3 SAJDI: "gHotSpotVMTypes was not initialized 
>>>>>> properly in
>>>>>>                the remote process"
>>>>>>
>>>>>> Here is the URL for the webrev:
>>>>>>
>>>>>>    http://cr.openjdk.java.net/~dcubed/6987812-webrev/0/
>>>>>>
>>>>>> Here is an overview of the changes:
>>>>>>
>>>>>> - Reorder the code in HotSpotTypeDataBase.readVMTypes() to lookup
>>>>>>  and decode the 'gHotSpotVMTypes' symbol first. This should help
>>>>>>  make any future failures in this area more consistent.
>>>>>>
>>>>>> - COFFFileParser changes:
>>>>>>  - add comments to clarify some of the algorithms
>>>>>>  - read 'Base Of Data' field in optional header when PE32
>>>>>>    format COFF file is read
>>>>>>  - change ExportDirectoryTableImpl to return the 'Export RVA' field
>>>>>>    without modification and to return the 'Forwarder RVA' field
>>>>>>    after adjusting the address into a file offset
>>>>>>
>>>>>> - update debugger/win32/coff/DumpExports to include more info about
>>>>>>  the section headers and to dump the exported symbol info in a more
>>>>>>  understandable order
>>>>>>
>>>>>> - update debugger/win32/coff/TestParser to more clearly access the
>>>>>>  section header using 1-based indices instead of 0-based indices
>>>>>>
>>>>>> - update the static initializer in 
>>>>>> debugger/windbg/WindbgDebuggerLocal
>>>>>>  to use different library loading logic for dbgeng.dll and 
>>>>>> dbghelp.dll.
>>>>>>  The library pair is searched for in:
>>>>>>
>>>>>>   - $JAVA_HOME/jre/bin
>>>>>>   - dir named by DEBUGGINGTOOLSFORWINDOWS environment variable
>>>>>>   - the "Debugging Tools For Windows" program directory
>>>>>>   - the "Debugging Tools For Windows (x86)" program directory
>>>>>>   - the "Debugging Tools For Windows (x64)" program directory
>>>>>>   - the system directory (WINDOWS/system32 is searched last)
>>>>>>
>>>>>> - the sawwindb.dll is now explicitly loaded from $JAVA_HOME/jre/bin
>>>>>>
>>>>>> Thanks, in advance, for any reviews.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>

From daniel.daugherty at oracle.com  Thu Dec 23 10:29:13 2010
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Thu, 23 Dec 2010 18:29:13 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6987812: 2/3 SAJDI: "gHotSpotVMTypes was
	not initialized properly in the remote process"
Message-ID: <20101223182916.8B8ED476B3@hg.openjdk.java.net>

Changeset: d6cd0d55d0b5
Author:    dcubed
Date:      2010-12-23 07:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d6cd0d55d0b5

6987812: 2/3 SAJDI: "gHotSpotVMTypes was not initialized properly in the remote process"
Summary: Change ExportDirectoryTableImpl to return the 'Export RVA' field without modification. Read 'Base Of Data' field in optional header when PE32 format COFF file is read. Refine search for dbgeng.dll and dbghelp.dll. Other cleanups.
Reviewed-by: swamyv, poonam

! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/COFFFileParser.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/DumpExports.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/TestParser.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java


From daniel.daugherty at oracle.com  Thu Dec 23 15:25:17 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 23 Dec 2010 16:25:17 -0700
Subject: code review for very small jstat fix (7005984)
Message-ID: <4D13DA5D.6030807@oracle.com>

Greetings,

I need a code review for a very small jstat fix:

    http://cr.openjdk.java.net/~dcubed/7005984-webrev/0/

It's going to take me longer to remember how to run the
associated tests in JPRT than it is to review this 3 line fix...

Dan

From kelly.ohair at oracle.com  Thu Dec 23 17:04:20 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 23 Dec 2010 17:04:20 -0800
Subject: code review for very small jstat fix (7005984)
In-Reply-To: <4D13DA5D.6030807@oracle.com>
References: <4D13DA5D.6030807@oracle.com>
Message-ID: <719A9EA6-D6C3-4381-982A-F9474483B1D0@oracle.com>

Not that I completely understand this change, but it looks like it  
makes sense.

-kto

On Dec 23, 2010, at 3:25 PM, Daniel D. Daugherty wrote:

> Greetings,
>
> I need a code review for a very small jstat fix:
>
>   http://cr.openjdk.java.net/~dcubed/7005984-webrev/0/
>
> It's going to take me longer to remember how to run the
> associated tests in JPRT than it is to review this 3 line fix...
>
> Dan


From David.Holmes at oracle.com  Thu Dec 23 17:15:46 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 24 Dec 2010 11:15:46 +1000
Subject: code review for very small jstat fix (7005984)
In-Reply-To: <4D13DA5D.6030807@oracle.com>
References: <4D13DA5D.6030807@oracle.com>
Message-ID: <4D13F442.1030103@oracle.com>

Looks okay to me.

David

Daniel D. Daugherty said the following on 12/24/10 09:25:
> Greetings,
> 
> I need a code review for a very small jstat fix:
> 
>    http://cr.openjdk.java.net/~dcubed/7005984-webrev/0/
> 
> It's going to take me longer to remember how to run the
> associated tests in JPRT than it is to review this 3 line fix...
> 
> Dan

From poonam.bajaj at oracle.com  Thu Dec 23 17:50:09 2010
From: poonam.bajaj at oracle.com (Poonam Bajaj)
Date: Fri, 24 Dec 2010 07:20:09 +0530
Subject: code review for very small jstat fix (7005984)
In-Reply-To: <4D13DA5D.6030807@oracle.com>
References: <4D13DA5D.6030807@oracle.com>
Message-ID: <4D13FC51.4040005@oracle.com>

Looks good to me.

Thanks,
Poonam


On 12/24/2010 4:55 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> I need a code review for a very small jstat fix:
>
>    http://cr.openjdk.java.net/~dcubed/7005984-webrev/0/
>
> It's going to take me longer to remember how to run the
> associated tests in JPRT than it is to review this 3 line fix...
>
> Dan

From daniel.daugherty at oracle.com  Thu Dec 23 20:33:15 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 23 Dec 2010 21:33:15 -0700
Subject: code review for very small jstat fix (7005984)
In-Reply-To: <719A9EA6-D6C3-4381-982A-F9474483B1D0@oracle.com>
References: <4D13DA5D.6030807@oracle.com>
	<719A9EA6-D6C3-4381-982A-F9474483B1D0@oracle.com>
Message-ID: <4D14228B.1060005@oracle.com>

Kelly, David and Poonam,

Thanks for the reviews!

Dan


On 12/23/2010 6:04 PM, Kelly O'Hair wrote:
> Not that I completely understand this change, but it looks like it 
> makes sense.
>
> -kto

On 12/23/2010 6:15 PM, David Holmes wrote:
 > Looks okay to me.
 >
 > David

On 12/23/2010 6:50 PM, Poonam Bajaj wrote:
 > Looks good to me.
 >
 > Thanks,
 > Poonam

>
> On Dec 23, 2010, at 3:25 PM, Daniel D. Daugherty wrote:
>
>> Greetings,
>>
>> I need a code review for a very small jstat fix:
>>
>>   http://cr.openjdk.java.net/~dcubed/7005984-webrev/0/
>>
>> It's going to take me longer to remember how to run the
>> associated tests in JPRT than it is to review this 3 line fix...
>>
>> Dan
>

From john.coomes at oracle.com  Thu Dec 23 20:46:25 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 24 Dec 2010 04:46:25 +0000
Subject: hg: jdk7/hotspot-rt: 17 new changesets
Message-ID: <20101224044625.92434476F0@hg.openjdk.java.net>

Changeset: d61adc5101e0
Author:    cl
Date:      2010-12-16 18:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/d61adc5101e0

Added tag jdk7-b122 for changeset f1591eed71f6

! .hgtags

Changeset: 55566844106b
Author:    ohair
Date:      2010-12-06 10:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/55566844106b

7001720: copyright templates not rebranded
Reviewed-by: mchung

! make/templates/bsd-header
! make/templates/gpl-cp-header
! make/templates/gpl-header

Changeset: 5be437606a75
Author:    ohair
Date:      2010-12-15 15:24 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/5be437606a75

Merge


Changeset: d94daa2acb2c
Author:    ohair
Date:      2010-12-16 19:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/d94daa2acb2c

Merge


Changeset: f4c95f4b7590
Author:    ohair
Date:      2010-12-18 18:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/f4c95f4b7590

6909026: Change GNU make version requirement to 3.81
Reviewed-by: robilad

! README
! README-builds.html

Changeset: 6d8ed82e5070
Author:    ohair
Date:      2010-12-20 08:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/6d8ed82e5070

6909331: Add vsvars.sh to the jdk repository (handy cygwin way to get vcvars32.bat run)
Reviewed-by: robilad

+ make/scripts/vsvars.sh

Changeset: 2dfa4b3ffb15
Author:    jqzuo
Date:      2010-12-01 14:35 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/2dfa4b3ffb15

Merge


Changeset: 58a44f077f6a
Author:    jqzuo
Date:      2010-12-09 16:05 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/58a44f077f6a

Merge


Changeset: 89f2e9a9ea8e
Author:    jqzuo
Date:      2010-12-13 11:34 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/89f2e9a9ea8e

Merge


Changeset: 8f03f266666a
Author:    jqzuo
Date:      2010-12-20 13:05 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/8f03f266666a

Merge


Changeset: 6f7376db67f8
Author:    jqzuo
Date:      2010-12-21 11:43 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/6f7376db67f8

Merge


Changeset: e6a650447dfe
Author:    igor
Date:      2010-12-06 00:43 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/e6a650447dfe

Merge


Changeset: 9dd65b426626
Author:    igor
Date:      2010-12-08 01:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/9dd65b426626

Merge


Changeset: c71d8feeb2ea
Author:    herrick
Date:      2010-12-12 22:56 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/c71d8feeb2ea

Merge


Changeset: ca5471357681
Author:    herrick
Date:      2010-12-20 13:13 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/ca5471357681

Merge


Changeset: ed6950da30cf
Author:    igor
Date:      2010-12-21 14:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/ed6950da30cf

Merge


Changeset: 4c20b4f753e3
Author:    cl
Date:      2010-12-22 15:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/4c20b4f753e3

Added tag jdk7-b123 for changeset ed6950da30cf

! .hgtags


From john.coomes at oracle.com  Thu Dec 23 20:46:34 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 24 Dec 2010 04:46:34 +0000
Subject: hg: jdk7/hotspot-rt/corba: 20 new changesets
Message-ID: <20101224044648.5B22B476F1@hg.openjdk.java.net>

Changeset: ccc68bc57c82
Author:    cl
Date:      2010-12-16 18:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/ccc68bc57c82

Added tag jdk7-b122 for changeset 1523a060032c

! .hgtags

Changeset: 88ac4daf5d0e
Author:    yhuang
Date:      2010-12-05 20:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/88ac4daf5d0e

6925851: Localize JRE into pt_BR
Reviewed-by: mfang, psun

+ src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties

Changeset: 2367ae41663f
Author:    mfang
Date:      2010-12-05 18:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/2367ae41663f

Merge


Changeset: 0bf5592fb265
Author:    ohair
Date:      2010-12-15 15:24 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/0bf5592fb265

Merge


Changeset: e8188d64f51f
Author:    ohair
Date:      2010-12-16 19:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/e8188d64f51f

Merge


Changeset: 39e071e5adaf
Author:    ohair
Date:      2010-12-18 18:29 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/39e071e5adaf

6909026: Change GNU make version requirement to 3.81
Reviewed-by: robilad

! make/common/shared/Platform.gmk

Changeset: e0f7ed041196
Author:    skoppar
Date:      2010-10-07 00:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/e0f7ed041196

6714797: InitialContext.close does not close NIO socket connections
Reviewed-by: asaha

! src/share/classes/com/sun/corba/se/impl/transport/CorbaConnectionCacheBase.java
! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java
! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java
! src/share/classes/com/sun/corba/se/pept/transport/ConnectionCache.java
! src/share/classes/com/sun/corba/se/spi/transport/CorbaConnection.java

Changeset: 459c07278c3c
Author:    skoppar
Date:      2010-10-07 00:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/459c07278c3c

6893109: memory leak in readObject() and writeObject() using idlj from jdk 1.6.0_14
Reviewed-by: asaha

! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/Stub.java

Changeset: 2d3622317730
Author:    skoppar
Date:      2010-10-07 00:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/2d3622317730

6896157: unsynchronized hashmap in com.sun.corba.se.impl.transport.SelectorImpl.createReaderThread
Reviewed-by: asaha

! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java

Changeset: 5f026ab0098c
Author:    skoppar
Date:      2010-10-07 00:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/5f026ab0098c

6929137: java-corba: Locking too broad in com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl
Reviewed-by: asaha

! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java

Changeset: 34af2070439b
Author:    skoppar
Date:      2010-10-07 01:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/34af2070439b

6948223: Corba issue, fail to reload object
Reviewed-by: asaha

! src/share/classes/com/sun/corba/se/impl/oa/poa/AOMEntry.java
! src/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorBase_R.java

Changeset: ff0f02a67881
Author:    vikram
Date:      2010-11-29 22:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/ff0f02a67881

6382377: incorrect Exception is given to interceptor
6828768: RMI-IIOP EJB clients do not fail over due to defect in JDK 1.6.0_12
Summary: Also reviewed by ken.cavanaugh at oracle.com
Reviewed-by: skoppar

! src/share/classes/com/sun/corba/se/impl/encoding/BufferManagerWriteStream.java
! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java

Changeset: 6fe70c295e96
Author:    skoppar
Date:      2010-11-21 21:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/6fe70c295e96

6980681: CORBA deadlock in Java SE beleived to be related to CR 6238477
Summary: Also reviewed by ken.cavanaugh at oracle.com
Reviewed-by: poonam

! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java

Changeset: d2049cfdf02b
Author:    asaha
Date:      2010-12-01 16:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/d2049cfdf02b

Merge

! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java

Changeset: e6f42f5d6d60
Author:    lana
Date:      2010-12-05 15:20 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/e6f42f5d6d60

Merge


Changeset: 5d9708346d50
Author:    miroslawzn
Date:      2010-12-08 10:43 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/5d9708346d50

6877056: SVUID calculated for java.lang.Enum is not 0L
Reviewed-by: raginip

! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java

Changeset: 33ca1bceec2d
Author:    skoppar
Date:      2010-12-05 22:22 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/33ca1bceec2d

7004713: regression: cannot find symbol: variable delegate failed compile _Stub
Summary: Also reviewed by ken.cavanaugh at oracle.com
Reviewed-by: asaha

! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/Stub.java

Changeset: 18e9f50c8d13
Author:    lana
Date:      2010-12-12 10:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/18e9f50c8d13

Merge


Changeset: a230c142628c
Author:    lana
Date:      2010-12-20 17:18 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/a230c142628c

Merge


Changeset: 70cff21e5550
Author:    cl
Date:      2010-12-22 15:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/70cff21e5550

Added tag jdk7-b123 for changeset a230c142628c

! .hgtags


From john.coomes at oracle.com  Thu Dec 23 20:46:54 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 24 Dec 2010 04:46:54 +0000
Subject: hg: jdk7/hotspot-rt/jaxp: 8 new changesets
Message-ID: <20101224044654.E8BBC476F2@hg.openjdk.java.net>

Changeset: ced66f2b52cf
Author:    cl
Date:      2010-12-16 18:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/ced66f2b52cf

Added tag jdk7-b122 for changeset 03ff13d19c8f

! .hgtags

Changeset: 68ef5e4375d5
Author:    ohair
Date:      2010-12-03 08:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/68ef5e4375d5

Merge


Changeset: f810d59bcc3a
Author:    ohair
Date:      2010-12-15 15:29 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/f810d59bcc3a

Merge


Changeset: 4af8ef0521e3
Author:    ohair
Date:      2010-12-16 19:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/4af8ef0521e3

Merge


Changeset: 46ef275f0d5a
Author:    lana
Date:      2010-12-05 15:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/46ef275f0d5a

Merge


Changeset: 74d9007e9a6e
Author:    lana
Date:      2010-12-12 10:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/74d9007e9a6e

Merge


Changeset: e2aedea6495d
Author:    lana
Date:      2010-12-20 17:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/e2aedea6495d

Merge


Changeset: a5de4610febf
Author:    cl
Date:      2010-12-22 15:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/a5de4610febf

Added tag jdk7-b123 for changeset e2aedea6495d

! .hgtags


From john.coomes at oracle.com  Thu Dec 23 20:47:01 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 24 Dec 2010 04:47:01 +0000
Subject: hg: jdk7/hotspot-rt/jaxws: 8 new changesets
Message-ID: <20101224044701.BDD3A476F3@hg.openjdk.java.net>

Changeset: f74fc1dbef46
Author:    cl
Date:      2010-12-16 18:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/f74fc1dbef46

Added tag jdk7-b122 for changeset 17b6c48a3449

! .hgtags

Changeset: 0f117d4f6847
Author:    ohair
Date:      2010-12-03 08:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/0f117d4f6847

Merge


Changeset: a5fc960570f6
Author:    ohair
Date:      2010-12-15 15:29 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/a5fc960570f6

Merge


Changeset: 2518d26fa43c
Author:    ohair
Date:      2010-12-16 19:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/2518d26fa43c

Merge


Changeset: 76ea68d0ffa2
Author:    lana
Date:      2010-12-05 15:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/76ea68d0ffa2

Merge


Changeset: ab1046d981c6
Author:    lana
Date:      2010-12-12 10:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/ab1046d981c6

Merge


Changeset: 5a8e43bcce56
Author:    lana
Date:      2010-12-20 17:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/5a8e43bcce56

Merge


Changeset: 764fec69c128
Author:    cl
Date:      2010-12-22 15:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/764fec69c128

Added tag jdk7-b123 for changeset 5a8e43bcce56

! .hgtags


From john.coomes at oracle.com  Thu Dec 23 20:52:11 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 24 Dec 2010 04:52:11 +0000
Subject: hg: jdk7/hotspot-rt/jdk: 112 new changesets
Message-ID: <20101224051057.2B5DD476F6@hg.openjdk.java.net>

Changeset: e8ef99adf42b
Author:    cl
Date:      2010-12-16 18:18 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e8ef99adf42b

Added tag jdk7-b122 for changeset ac311eb325bf

! .hgtags

Changeset: 19c125efeda3
Author:    jrose
Date:      2010-10-30 21:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/19c125efeda3

6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions
Summary: JDK changes which run atop the corresponding JVM hook
Reviewed-by: never, twisti

! src/share/classes/java/dyn/MethodHandle.java
! src/share/classes/java/dyn/MethodHandles.java
! src/share/classes/sun/dyn/AdapterMethodHandle.java
! src/share/classes/sun/dyn/BoundMethodHandle.java
+ src/share/classes/sun/dyn/InvokeGeneric.java
! src/share/classes/sun/dyn/Invokers.java
! src/share/classes/sun/dyn/MethodHandleImpl.java
! src/share/classes/sun/dyn/MethodHandleNatives.java
! src/share/classes/sun/dyn/MethodTypeImpl.java
! src/share/classes/sun/dyn/util/ValueConversions.java
+ test/java/dyn/InvokeGenericTest.java
! test/java/dyn/MethodHandlesTest.java

Changeset: 45f5055dd53f
Author:    jrose
Date:      2010-10-30 21:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/45f5055dd53f

6981777: implement JSR 292 EG adjustments from summer 2010
Reviewed-by: twisti

- src/share/classes/java/dyn/BootstrapMethod.java
! src/share/classes/java/dyn/CallSite.java
! src/share/classes/java/dyn/ConstantCallSite.java
- src/share/classes/java/dyn/InvokeDynamic.java
! src/share/classes/java/dyn/Linkage.java
- src/share/classes/java/dyn/LinkagePermission.java
! src/share/classes/java/dyn/MethodHandle.java
- src/share/classes/java/dyn/MethodHandleProvider.java
! src/share/classes/java/dyn/MethodHandles.java
! src/share/classes/java/dyn/MethodType.java
+ src/share/classes/java/dyn/VolatileCallSite.java
! src/share/classes/java/dyn/package-info.java
! src/share/classes/sun/dyn/AdapterMethodHandle.java
! src/share/classes/sun/dyn/BoundMethodHandle.java
! src/share/classes/sun/dyn/CallSiteImpl.java
! src/share/classes/sun/dyn/FilterGeneric.java
! src/share/classes/sun/dyn/FilterOneArgument.java
! src/share/classes/sun/dyn/FromGeneric.java
! src/share/classes/sun/dyn/Invokers.java
- src/share/classes/sun/dyn/JavaMethodHandle.java
! src/share/classes/sun/dyn/MethodHandleImpl.java
! src/share/classes/sun/dyn/SpreadGeneric.java
! src/share/classes/sun/dyn/ToGeneric.java
! src/share/classes/sun/dyn/util/ValueConversions.java
! src/share/classes/sun/dyn/util/VerifyAccess.java
! src/share/classes/sun/dyn/util/Wrapper.java
! test/java/dyn/InvokeGenericTest.java
- test/java/dyn/JavaDocExamples.java
+ test/java/dyn/JavaDocExamplesTest.java
! test/java/dyn/MethodHandlesTest.java

Changeset: f50d2c66f585
Author:    jrose
Date:      2010-11-22 22:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f50d2c66f585

6979327: method handle invocation should use casts instead of type parameters to specify return type
Summary: Change result type parameters to result type casts.  (Also, replace private placeholder class InvokeDynamic.)
Reviewed-by: twisti

! make/java/dyn/Makefile
+ src/share/classes/java/dyn/InvokeDynamic.java
! src/share/classes/java/dyn/MethodHandle.java
! src/share/classes/sun/dyn/AdapterMethodHandle.java
! src/share/classes/sun/dyn/CallSiteImpl.java
! src/share/classes/sun/dyn/FilterGeneric.java
! src/share/classes/sun/dyn/FromGeneric.java
! src/share/classes/sun/dyn/MethodHandleImpl.java
! src/share/classes/sun/dyn/SpreadGeneric.java
! src/share/classes/sun/dyn/ToGeneric.java
! test/java/dyn/InvokeGenericTest.java
! test/java/dyn/JavaDocExamplesTest.java
! test/java/dyn/MethodHandlesTest.java

Changeset: 32d6d7a39220
Author:    jrose
Date:      2010-12-02 02:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/32d6d7a39220

7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute
Reviewed-by: twisti

! src/share/classes/java/dyn/package-info.java

Changeset: a451f7948ec5
Author:    jrose
Date:      2010-12-02 02:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a451f7948ec5

7001423: JSR 292 bytecode enhancements need unit tests
Reviewed-by: twisti

+ test/java/dyn/InvokeDynamicPrintArgs.java
+ test/java/dyn/indify/Indify.java

Changeset: 6a0245a8f714
Author:    jrose
Date:      2010-12-02 03:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6a0245a8f714

Merge

- make/common/Rules-SCCS.gmk
- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
- src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java
- src/share/classes/sun/java2d/pisces/LineSink.java
- src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java
- src/share/classes/sun/security/krb5/KrbKdcReq.java
- src/share/classes/sun/security/krb5/internal/TCPClient.java
- src/share/classes/sun/security/krb5/internal/UDPClient.java
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/java/nio/channels/AsynchronousDatagramChannel/Basic.java
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp
- test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh
- test/tools/launcher/VerifyExceptions.java

Changeset: 7fc85363b44c
Author:    jrose
Date:      2010-12-03 11:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7fc85363b44c

Merge


Changeset: 0db159ce2517
Author:    jrose
Date:      2010-12-16 00:32 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0db159ce2517

Merge

- src/share/classes/sun/net/httpserver/SelectorCache.java

Changeset: 75040738aec9
Author:    jrose
Date:      2010-12-16 15:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/75040738aec9

7001424: implement JSR 292 EG adjustments, November 2010
Reviewed-by: twisti

! src/share/classes/java/dyn/CallSite.java
! src/share/classes/java/dyn/ClassValue.java
! src/share/classes/java/dyn/ConstantCallSite.java
! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java
! src/share/classes/java/dyn/MethodHandle.java
! src/share/classes/java/dyn/MethodHandles.java
! src/share/classes/java/dyn/MethodType.java
+ src/share/classes/java/dyn/MutableCallSite.java
+ src/share/classes/java/dyn/Switcher.java
! src/share/classes/java/dyn/VolatileCallSite.java
! src/share/classes/java/dyn/package-info.java
! test/java/dyn/ClassValueTest.java
! test/java/dyn/InvokeDynamicPrintArgs.java
! test/java/dyn/JavaDocExamplesTest.java
! test/java/dyn/MethodHandlesTest.java

Changeset: 04c9b38d6bf3
Author:    trims
Date:      2010-12-16 20:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/04c9b38d6bf3

Merge

- src/share/classes/java/dyn/BootstrapMethod.java
! src/share/classes/java/dyn/InvokeDynamic.java
- src/share/classes/java/dyn/LinkagePermission.java
- src/share/classes/java/dyn/MethodHandleProvider.java
- src/share/classes/sun/dyn/JavaMethodHandle.java
- test/java/dyn/JavaDocExamples.java

Changeset: beb9f3298ad3
Author:    andrew
Date:      2010-11-23 02:17 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/beb9f3298ad3

7000225: Sanity check on sane-alsa-headers is broken
Summary: Fix use of tab separators, ${alsa_version} expansion and conditional
Reviewed-by: ohair

! make/common/shared/Sanity.gmk

Changeset: fd6873594ae2
Author:    ohair
Date:      2010-11-30 17:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fd6873594ae2

6987107: Add variable to add to but not modify non-fcs version string
Reviewed-by: jcoomes, dholmes, andrew, kvn

! make/common/shared/Defs.gmk
! make/jprt.gmk

Changeset: 9a976162a702
Author:    ohair
Date:      2010-12-03 08:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9a976162a702

Merge


Changeset: 3ead3b641162
Author:    ohair
Date:      2010-12-03 21:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3ead3b641162

Merge


Changeset: 5e54a0a879e8
Author:    mfang
Date:      2010-11-30 22:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5e54a0a879e8

6675400: "Details" in English has to be "Details" in German
Reviewed-by: yhuang

! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties

Changeset: dd9dbdf2c508
Author:    mfang
Date:      2010-12-02 14:40 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/dd9dbdf2c508

6851050: unnecessary full stop character in ja jdi messages
Reviewed-by: ogino

! src/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties

Changeset: e3ecd9555ff0
Author:    yhuang
Date:      2010-12-02 02:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e3ecd9555ff0

6925851: Localize JRE into pt_BR
Reviewed-by: mfang, psun

! make/common/Defs.gmk
! make/java/util/FILES_java.gmk
+ src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties
+ src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties
+ src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties
+ src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties
+ src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
+ src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
+ src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties
+ src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties
+ src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java
+ src/share/classes/sun/awt/resources/awt_pt_BR.properties
+ src/share/classes/sun/launcher/resources/launcher_pt_BR.properties
+ src/share/classes/sun/management/resources/agent_pt_BR.properties
+ src/share/classes/sun/misc/resources/Messages_pt_BR.java
+ src/share/classes/sun/print/resources/serviceui_pt_BR.properties
+ src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties
+ src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties
+ src/share/classes/sun/security/util/AuthResources_pt_BR.java
+ src/share/classes/sun/security/util/Resources_pt_BR.java
+ src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
+ src/share/classes/sun/util/logging/resources/logging_pt_BR.properties
+ src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java
+ src/windows/classes/sun/awt/windows/awtLocalization_pt_BR.properties
! src/windows/native/sun/jkernel/kernel.rc
+ src/windows/native/sun/jkernel/kernel_pt_BR.rc

Changeset: 65a17e71c12e
Author:    yhuang
Date:      2010-12-02 20:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/65a17e71c12e

Merge


Changeset: 750150b298fc
Author:    mfang
Date:      2010-12-03 17:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/750150b298fc

6566218: l10n of 6476932
Reviewed-by: yhuang

! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java
! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java
! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java

Changeset: 4f5e4145da23
Author:    mfang
Date:      2010-12-03 17:20 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4f5e4145da23

6579775: l10n update after 6212566
Reviewed-by: yhuang

! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties

Changeset: 9eaf28c91567
Author:    mfang
Date:      2010-12-03 17:22 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9eaf28c91567

6708417: On Chinese OS Applet string is appearing in English
Reviewed-by: yhuang

! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java

Changeset: 2f7a3aae0331
Author:    mfang
Date:      2010-12-03 17:24 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2f7a3aae0331

6745048: Unnecessary surfix "(O)"  in JFileChooser open button text
Reviewed-by: yhuang

! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties

Changeset: e31ac89c72ce
Author:    mfang
Date:      2010-12-03 17:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e31ac89c72ce

6785462: Missing "(O)" in JFileChooser Open button in Windows LAF
Reviewed-by: yhuang

! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties

Changeset: 5b1b2c521874
Author:    mfang
Date:      2010-12-03 17:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5b1b2c521874

6896693: [fr] keytool: wrong message format in fr locale
Reviewed-by: yhuang

! src/share/classes/sun/security/util/Resources_fr.java
! src/share/classes/sun/security/util/Resources_it.java

Changeset: 35b2227806bc
Author:    mfang
Date:      2010-12-05 17:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/35b2227806bc

7000729: NLS: rmic.properties cannot be processed by translation team
Reviewed-by: ogino

! src/share/classes/sun/rmi/rmic/resources/rmic.properties
! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties
! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties

Changeset: 66117705c085
Author:    mfang
Date:      2010-12-05 18:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/66117705c085

7004706: l10n of 7000752 Duplicate entry in RowSetResourceBundles.properties
Reviewed-by: ogino

! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties

Changeset: 8f2965949d36
Author:    mfang
Date:      2010-12-05 18:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8f2965949d36

Merge


Changeset: bc577ec0d3d1
Author:    ohair
Date:      2010-12-06 10:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/bc577ec0d3d1

7001720: copyright templates not rebranded
Reviewed-by: mchung

! make/templates/bsd-header
! make/templates/gpl-cp-header
! make/templates/gpl-header

Changeset: b99b1789dc4c
Author:    ohair
Date:      2010-12-13 10:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b99b1789dc4c

Merge


Changeset: 27be4ed38e97
Author:    ohair
Date:      2010-12-15 15:30 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/27be4ed38e97

Merge

! make/common/Defs.gmk
! make/common/shared/Sanity.gmk
! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties

Changeset: 12da5e10cab8
Author:    ohair
Date:      2010-12-16 19:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/12da5e10cab8

Merge


Changeset: 435b477c4f14
Author:    ohair
Date:      2010-12-18 18:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/435b477c4f14

6909026: Change GNU make version requirement to 3.81
Reviewed-by: robilad

! make/common/shared/Defs-versions.gmk

Changeset: 024fe931de8c
Author:    lana
Date:      2010-12-03 17:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/024fe931de8c

Merge

- src/share/classes/sun/security/krb5/KrbKdcReq.java
- src/share/classes/sun/security/krb5/internal/TCPClient.java
- src/share/classes/sun/security/krb5/internal/UDPClient.java
- src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java

Changeset: 15e3f6f4a433
Author:    bae
Date:      2010-12-05 15:51 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/15e3f6f4a433

6980281: SWAT: SwingSet2 got core dumped in Solaris-AMD64 using b107 swat build
Reviewed-by: prr, ohair

! make/common/Defs-solaris.gmk
! make/common/shared/Compiler-sun.gmk

Changeset: 1d4340015b85
Author:    srl
Date:      2010-12-06 16:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1d4340015b85

6886358: layout code update
Reviewed-by: igor, prr

! make/sun/font/FILES_c.gmk
! src/share/classes/sun/font/FontUtilities.java
! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp
! src/share/native/sun/font/layout/ArabicLayoutEngine.h
! src/share/native/sun/font/layout/ArabicShaping.cpp
! src/share/native/sun/font/layout/CanonData.cpp
! src/share/native/sun/font/layout/CanonShaping.h
! src/share/native/sun/font/layout/ClassDefinitionTables.cpp
! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp
! src/share/native/sun/font/layout/ContextualSubstSubtables.h
! src/share/native/sun/font/layout/CoverageTables.cpp
! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp
! src/share/native/sun/font/layout/DeviceTables.cpp
! src/share/native/sun/font/layout/ExtensionSubtables.cpp
! src/share/native/sun/font/layout/ExtensionSubtables.h
! src/share/native/sun/font/layout/Features.cpp
! src/share/native/sun/font/layout/GXLayoutEngine.cpp
! src/share/native/sun/font/layout/GXLayoutEngine.h
! src/share/native/sun/font/layout/GlyphIterator.cpp
! src/share/native/sun/font/layout/GlyphIterator.h
! src/share/native/sun/font/layout/GlyphPositionAdjustments.cpp
! src/share/native/sun/font/layout/GlyphPositionAdjustments.h
! src/share/native/sun/font/layout/GlyphPositioningTables.cpp
! src/share/native/sun/font/layout/GlyphPositioningTables.h
! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp
! src/share/native/sun/font/layout/GlyphPosnLookupProc.h
! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp
! src/share/native/sun/font/layout/GlyphSubstLookupProc.h
! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp
! src/share/native/sun/font/layout/GlyphSubstitutionTables.h
! src/share/native/sun/font/layout/HanLayoutEngine.cpp
! src/share/native/sun/font/layout/HanLayoutEngine.h
+ src/share/native/sun/font/layout/HangulLayoutEngine.cpp
+ src/share/native/sun/font/layout/HangulLayoutEngine.h
- src/share/native/sun/font/layout/HebrewLigatureData.cpp
- src/share/native/sun/font/layout/HebrewShaping.cpp
- src/share/native/sun/font/layout/HebrewShaping.h
+ src/share/native/sun/font/layout/ICUFeatures.h
! src/share/native/sun/font/layout/IndicClassTables.cpp
! src/share/native/sun/font/layout/IndicLayoutEngine.cpp
! src/share/native/sun/font/layout/IndicLayoutEngine.h
! src/share/native/sun/font/layout/IndicReordering.cpp
! src/share/native/sun/font/layout/IndicReordering.h
! src/share/native/sun/font/layout/KernTable.cpp
! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp
! src/share/native/sun/font/layout/KhmerLayoutEngine.h
! src/share/native/sun/font/layout/KhmerReordering.cpp
! src/share/native/sun/font/layout/LEFontInstance.cpp
! src/share/native/sun/font/layout/LEFontInstance.h
! src/share/native/sun/font/layout/LEGlyphStorage.cpp
! src/share/native/sun/font/layout/LEGlyphStorage.h
! src/share/native/sun/font/layout/LEInsertionList.cpp
! src/share/native/sun/font/layout/LEInsertionList.h
! src/share/native/sun/font/layout/LELanguages.h
! src/share/native/sun/font/layout/LEScripts.h
! src/share/native/sun/font/layout/LEStandalone.h
! src/share/native/sun/font/layout/LESwaps.h
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LayoutEngine.h
! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/LookupProcessor.h
! src/share/native/sun/font/layout/MPreFixups.cpp
! src/share/native/sun/font/layout/MPreFixups.h
! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp
! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp
! src/share/native/sun/font/layout/MultipleSubstSubtables.h
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h
! src/share/native/sun/font/layout/OpenTypeTables.h
! src/share/native/sun/font/layout/OpenTypeUtilities.cpp
! src/share/native/sun/font/layout/PairPositioningSubtables.cpp
! src/share/native/sun/font/layout/ScriptAndLanguage.cpp
! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp
! src/share/native/sun/font/layout/ScriptAndLanguageTags.h
! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp
! src/share/native/sun/font/layout/ShapingTypeData.cpp
! src/share/native/sun/font/layout/SubstitutionLookups.cpp
! src/share/native/sun/font/layout/SubstitutionLookups.h
! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp
! src/share/native/sun/font/layout/ThaiLayoutEngine.h
+ src/share/native/sun/font/layout/TibetanLayoutEngine.cpp
+ src/share/native/sun/font/layout/TibetanLayoutEngine.h
+ src/share/native/sun/font/layout/TibetanReordering.cpp
+ src/share/native/sun/font/layout/TibetanReordering.h
+ test/java/awt/font/TextLayout/TestOldHangul.java
+ test/java/awt/font/TextLayout/TestTibetan.java

Changeset: 47cd69eff641
Author:    flar
Date:      2010-12-06 21:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/47cd69eff641

6775317: Improve performance of non-AA transformed rectangles and single wide lines in software pipelines
Reviewed-by: jgodinez, prr

! make/sun/awt/Depend.mak
! make/sun/awt/FILES_c_unix.gmk
! make/sun/awt/FILES_c_windows.gmk
! make/sun/awt/FILES_export_unix.gmk
! make/sun/awt/FILES_export_windows.gmk
! make/sun/awt/make.depend
! make/sun/awt/mapfile-vers
! src/share/classes/sun/java2d/SurfaceData.java
+ src/share/classes/sun/java2d/loops/DrawParallelogram.java
+ src/share/classes/sun/java2d/loops/FillParallelogram.java
! src/share/classes/sun/java2d/loops/RenderLoops.java
! src/share/classes/sun/java2d/pipe/LoopPipe.java
! src/share/native/sun/java2d/loops/Any3Byte.c
! src/share/native/sun/java2d/loops/Any4Byte.c
! src/share/native/sun/java2d/loops/AnyByte.c
! src/share/native/sun/java2d/loops/AnyInt.c
! src/share/native/sun/java2d/loops/AnyShort.c
+ src/share/native/sun/java2d/loops/DrawParallelogram.c
+ src/share/native/sun/java2d/loops/FillParallelogram.c
! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c
! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h
! src/share/native/sun/java2d/loops/LoopMacros.h
! src/solaris/native/sun/java2d/loops/java2d_Mlib.c
! src/solaris/native/sun/java2d/loops/vis_FuncArray.c

Changeset: ad7feec4413e
Author:    miroslawzn
Date:      2010-12-08 15:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ad7feec4413e

6813208: pageDialog throws NPE from applet
Reviewed-by: ant, minqi

! src/windows/classes/sun/awt/windows/WFileDialogPeer.java
! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java

Changeset: 90dcea60577e
Author:    miroslawzn
Date:      2010-12-08 15:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/90dcea60577e

6859086: Dialog created by JOptionPane.showMessageDialog does not repaint sometimes
Reviewed-by: bae, chrisphi

! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp
! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h

Changeset: 2dff913337a8
Author:    lana
Date:      2010-12-09 21:55 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2dff913337a8

Merge

- src/share/classes/sun/net/httpserver/SelectorCache.java

Changeset: 0eeac8ca33e3
Author:    prr
Date:      2010-12-10 16:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0eeac8ca33e3

7005896: Java2D D3D pipeline doesn't recognise latest Windows OSes
Reviewed-by: bae, jgodinez

! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp
! src/windows/native/sun/java2d/d3d/D3DPipelineManager.h

Changeset: 23a3e724ee9d
Author:    dav
Date:      2010-12-01 14:43 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/23a3e724ee9d

6709453: (dav)Screen flickers when a JFrame switches to fullscreen mode
Reviewed-by: art, dcherepanov

! src/windows/classes/sun/awt/Win32GraphicsDevice.java

Changeset: 386b49abc195
Author:    denis
Date:      2010-12-01 17:25 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/386b49abc195

6945178: SecurityException upon drag-and-drop
Summary: A flag added to distinguish drop action handling.
Reviewed-by: uta, art

! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java

Changeset: df99592ad34f
Author:    dav
Date:      2010-12-02 19:53 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/df99592ad34f

7002173: java.awt package docs build warnings
Reviewed-by: ant

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

Changeset: 786f42385034
Author:    dmeetry
Date:      2010-12-04 02:27 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/786f42385034

6578041: Drag & Drop from Motif to Java does not work.
Summary: fixing java's interpretation of unsigned 32bit int as signed during an implicit conversion to 64bit int.
Reviewed-by: denis, chrisphi

! src/solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
! src/solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java

Changeset: 4bfe9244ede4
Author:    lana
Date:      2010-12-03 11:30 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4bfe9244ede4

Merge

- src/share/classes/sun/security/krb5/KrbKdcReq.java
- src/share/classes/sun/security/krb5/internal/TCPClient.java
- src/share/classes/sun/security/krb5/internal/UDPClient.java
- src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java

Changeset: df3aeffb636e
Author:    lana
Date:      2010-12-03 17:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/df3aeffb636e

Merge


Changeset: 2383ded24c27
Author:    dcherepanov
Date:      2010-12-07 21:02 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2383ded24c27

6984049: applet browser vendor rebranding changes (jdk7 only)
Reviewed-by: art

! src/share/classes/sun/applet/Main.java

Changeset: e9018c697557
Author:    lana
Date:      2010-12-13 16:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e9018c697557

Merge


Changeset: 6bb0d3464928
Author:    rupashka
Date:      2010-12-02 15:54 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6bb0d3464928

6639507: Title of javax.swing.JDialog is null while spec says it's empty
Reviewed-by: alexp

! src/share/classes/java/awt/Dialog.java
! src/share/classes/javax/swing/JDialog.java
+ test/javax/swing/JDialog/6639507/bug6639507.java

Changeset: 95159bdba902
Author:    rupashka
Date:      2010-12-02 18:02 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/95159bdba902

6988205: Test failed due to compilation failed, JTextComponent doesn't create drop locations with null bias.
Reviewed-by: alexp

+ test/javax/swing/DataTransfer/6456844/bug6456844.java

Changeset: 3122d9afafd5
Author:    okutsu
Date:      2010-12-08 12:50 +0900
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3122d9afafd5

4396385: [Fmt-Da] SimpleDateFormat too lenient when parsing 1-based hours
Reviewed-by: peytoia

! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/Bug4396385.java

Changeset: 35c13e43bbf3
Author:    okutsu
Date:      2010-12-08 13:02 +0900
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/35c13e43bbf3

6203034: [AC] AttributedCharacterIterator methods works wrong (run with respect differs from spec)
Reviewed-by: peytoia

! src/share/classes/java/text/AttributedCharacterIterator.java

Changeset: eff36d0a0615
Author:    okutsu
Date:      2010-12-08 13:09 +0900
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/eff36d0a0615

6653944: (cal) BuddhistCalendar yearOffset erased when deserialized
Reviewed-by: peytoia

! src/share/classes/sun/util/BuddhistCalendar.java
+ test/sun/util/calendar/Bug6653944.java

Changeset: 230822c90868
Author:    okutsu
Date:      2010-12-08 18:05 +0900
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/230822c90868

6457726: Character.isWhitespace JavaDoc has nonexistent char literals
Reviewed-by: peytoia

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

Changeset: 07f5669f1231
Author:    naoto
Date:      2010-12-08 15:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/07f5669f1231

6647615: Sample code in ListResourceBundle is not correct and causes a compile error.
Reviewed-by: peytoia

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

Changeset: 4c10246b3f62
Author:    okutsu
Date:      2010-12-09 12:36 +0900
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4c10246b3f62

6911839: Sles/SuSE 11 needs CJK support
Reviewed-by: peytoia

! make/sun/awt/Makefile

Changeset: ea504a083acd
Author:    naoto
Date:      2010-12-09 15:22 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ea504a083acd

7000507: javadoc warnings in java.util.Locale
7004335: Javadoc for Locale.toLangaugeTag() is unclear
7005320: (lc) doc: missing " in Locale.forLanguageTag code samples
Reviewed-by: okutsu

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

Changeset: eb78026c92a9
Author:    naoto
Date:      2010-12-09 11:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/eb78026c92a9

6486695: [Col] Doc: CollationElementIterator example assumes Collator.getInstance return type
Reviewed-by: okutsu

! src/share/classes/java/text/CollationElementIterator.java

Changeset: 71d76815eba6
Author:    naoto
Date:      2010-12-09 15:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/71d76815eba6

Merge


Changeset: 7e8acb2a9259
Author:    peytoia
Date:      2010-12-10 11:43 +0900
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7e8acb2a9259

6515695: [Col] java.text.RuleBasedCollator - JavaDoc "Examples" - Two bugs in sample code
Reviewed-by: okutsu

! src/share/classes/java/text/RuleBasedCollator.java

Changeset: 11b73cda876d
Author:    lana
Date:      2010-12-10 14:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/11b73cda876d

Merge

! src/share/classes/java/awt/Dialog.java
- src/share/classes/sun/net/httpserver/SelectorCache.java

Changeset: 97e54a18d599
Author:    naoto
Date:      2010-12-13 13:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/97e54a18d599

7002320: Locale.forLanguageTag()/toLanguageTag() not working properly with ja_JP_JP locale
Reviewed-by: dougfelt

! src/share/classes/java/util/Locale.java
! test/java/util/Locale/LocaleEnhanceTest.java

Changeset: 0df2e740bd4e
Author:    lana
Date:      2010-12-13 16:22 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0df2e740bd4e

Merge


Changeset: 374cc848d797
Author:    alanb
Date:      2010-12-01 13:49 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/374cc848d797

6709457: (fc) lock/tryLock() throws IOException "Access is denied" when file opened for append [win]
Reviewed-by: chegar

! src/share/classes/java/io/FileOutputStream.java
! src/share/classes/java/lang/ProcessBuilder.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/native/java/io/RandomAccessFile.c
! src/share/native/java/io/io_util.c
! src/share/native/java/io/io_util.h
! src/solaris/classes/java/lang/ProcessImpl.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/native/java/io/FileOutputStream_md.c
! src/solaris/native/java/io/io_util_md.h
! src/windows/classes/java/lang/ProcessImpl.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
! src/windows/classes/sun/nio/fs/WindowsChannelFactory.java
! src/windows/native/java/io/FileOutputStream_md.c
! src/windows/native/java/io/io_util_md.c
! src/windows/native/java/io/io_util_md.h
! src/windows/native/java/lang/ProcessImpl_md.c
! src/windows/native/sun/nio/ch/FileDispatcherImpl.c
+ test/java/nio/channels/FileChannel/AtomicAppend.java
! test/java/nio/channels/FileChannel/Lock.java
! test/java/nio/channels/FileChannel/Truncate.java

Changeset: a5ec2488bdc0
Author:    alanb
Date:      2010-12-01 19:40 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a5ec2488bdc0

Merge


Changeset: 8aabca72877c
Author:    darcy
Date:      2010-12-01 13:01 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8aabca72877c

7002594: Math.max and Math.min should use floatToRawIntBits() to check for -0.0
Reviewed-by: mduigou, lancea, alanb

! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/Float.java
! src/share/classes/java/lang/StrictMath.java
! src/share/classes/sun/misc/FpUtils.java

Changeset: 9e494de19690
Author:    dl
Date:      2010-12-01 21:46 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9e494de19690

7003745: Code style cleanups (sync from Dougs CVS)
Reviewed-by: chegar, dholmes

! src/share/classes/java/util/AbstractCollection.java
! src/share/classes/java/util/AbstractList.java
! src/share/classes/java/util/AbstractMap.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/ComparableTimSort.java
! src/share/classes/java/util/Random.java
! src/share/classes/java/util/Stack.java
! src/share/classes/java/util/TimSort.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java
! src/share/classes/java/util/concurrent/AbstractExecutorService.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/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/CountDownLatch.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/Exchanger.java
! src/share/classes/java/util/concurrent/Executor.java
! src/share/classes/java/util/concurrent/ExecutorCompletionService.java
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/concurrent/Future.java
! src/share/classes/java/util/concurrent/FutureTask.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/RecursiveAction.java
! src/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/Semaphore.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.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
! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/share/classes/java/util/concurrent/locks/LockSupport.java
! src/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
! test/java/util/concurrent/BlockingQueue/Interrupt.java
! test/java/util/concurrent/BlockingQueue/LoopHelpers.java
! test/java/util/concurrent/ConcurrentHashMap/LoopHelpers.java
! test/java/util/concurrent/ConcurrentHashMap/MapCheck.java
! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java
! test/java/util/concurrent/ConcurrentQueues/LoopHelpers.java
! test/java/util/concurrent/CopyOnWriteArrayList/EqualsRace.java
! test/java/util/concurrent/CopyOnWriteArraySet/RacingCows.java
! test/java/util/concurrent/CyclicBarrier/Basic.java
! test/java/util/concurrent/Exchanger/ExchangeLoops.java
! test/java/util/concurrent/Exchanger/LoopHelpers.java
! test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java
! test/java/util/concurrent/ExecutorCompletionService/LoopHelpers.java
! test/java/util/concurrent/Executors/Throws.java
! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java
! test/java/util/concurrent/FutureTask/CancelledFutureLoops.java
! test/java/util/concurrent/FutureTask/Customized.java
! test/java/util/concurrent/FutureTask/LoopHelpers.java
! test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java
! test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java
! test/java/util/concurrent/ThreadPoolExecutor/Custom.java
! test/java/util/concurrent/ThreadPoolExecutor/ScheduledTickleService.java
! test/java/util/concurrent/ThreadPoolExecutor/ShutdownNowExecuteRace.java
! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java
! test/java/util/concurrent/atomic/VMSupportsCS8.java
! test/java/util/concurrent/locks/Lock/FlakyMutex.java
! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java
! test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
! test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java
! test/java/util/concurrent/locks/ReentrantLock/LoopHelpers.java
! test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java
! test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
! test/java/util/concurrent/locks/ReentrantReadWriteLock/Bug6571733.java
! test/java/util/concurrent/locks/ReentrantReadWriteLock/LoopHelpers.java
! test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java
! test/java/util/concurrent/locks/ReentrantReadWriteLock/RWMap.java

Changeset: 8b2025d6f257
Author:    mchung
Date:      2010-12-01 15:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8b2025d6f257

6402006: FileInputStream.available() returns negative values when reading a large file
Reviewed-by: alanb

! src/windows/native/java/io/io_util_md.c
+ test/java/io/FileInputStream/LargeFileAvailable.java

Changeset: 0e0bdcd9c101
Author:    xuelei
Date:      2010-12-02 23:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0e0bdcd9c101

6979376: to have ldap filters tolerate underscore character in object identifier
Reviewed-by: weijun

! src/share/classes/com/sun/jndi/ldap/Filter.java
! test/com/sun/jndi/ldap/InvalidLdapFilters.java

Changeset: e3dbb8cd8820
Author:    weijun
Date:      2010-12-06 06:49 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e3dbb8cd8820

7004721: ktarg.sh fails when there's no default realm
Reviewed-by: xuelei

! test/sun/security/krb5/tools/ktarg.sh

Changeset: f32b03dc4e76
Author:    lana
Date:      2010-12-05 15:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f32b03dc4e76

Merge


Changeset: 51dd8df77406
Author:    lana
Date:      2010-12-05 16:08 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/51dd8df77406

Merge


Changeset: b8713c88c060
Author:    weijun
Date:      2010-12-06 10:46 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b8713c88c060

7004035: signed jar with only META-INF/* inside is not verifiable
Reviewed-by: mullan

! src/share/classes/sun/security/tools/JarSigner.java
! src/share/classes/sun/security/util/ManifestEntryVerifier.java
! src/share/classes/sun/security/util/SignatureFileVerifier.java
! test/sun/security/tools/jarsigner/JarSigningNonAscii.java
! test/sun/security/tools/jarsigner/concise_jarsigner.sh
+ test/sun/security/tools/jarsigner/onlymanifest.sh

Changeset: 6fc2e1efcb9a
Author:    weijun
Date:      2010-12-06 10:46 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6fc2e1efcb9a

7004168: jarsigner -verify checks for KeyUsage codesigning ext on all certs instead of just signing cert
Reviewed-by: mullan

! src/share/classes/sun/security/tools/JarSigner.java
+ test/sun/security/tools/jarsigner/checkusage.sh
! test/sun/security/tools/jarsigner/concise_jarsigner.sh

Changeset: 44d950400047
Author:    weijun
Date:      2010-12-06 10:48 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/44d950400047

6896700: Validation of signatures succeed when it should fail
Reviewed-by: wetmore

! src/share/classes/sun/security/rsa/RSASignature.java
+ test/sun/security/rsa/InvalidBitString.java
! test/sun/security/rsa/TestKeyPairGenerator.java

Changeset: c338757f2bc0
Author:    weijun
Date:      2010-12-06 10:48 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c338757f2bc0

6943352: SSL regression: RSAClientKeyExchange fails to pass securerandom arg to KeyGen
Reviewed-by: wetmore, xuelei

! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java

Changeset: 403785dc4493
Author:    weijun
Date:      2010-12-06 10:48 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/403785dc4493

6992964: FindBugs warnings in com.sun.security.auth.module.UnixSystem.java
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/module/NTSystem.java
! src/share/classes/com/sun/security/auth/module/SolarisSystem.java
! src/share/classes/com/sun/security/auth/module/UnixSystem.java

Changeset: fe9ead37938c
Author:    jjg
Date:      2010-12-05 20:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fe9ead37938c

7004021: docs should not assume -source 1.5
Reviewed-by: ohair

! make/docs/Makefile

Changeset: e7ab4e27f1e1
Author:    vinnie
Date:      2010-12-06 18:52 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e7ab4e27f1e1

6557615: Method toString() of java.security.Timestamp throws IndexOutOfBoundsException if CertPath has empty
Reviewed-by: mullan

! src/share/classes/java/security/Timestamp.java

Changeset: 9758119b818c
Author:    sherman
Date:      2010-12-06 13:18 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9758119b818c

6989148: (fs) zip provider should be available "out of the box"
Summary: zip filesystem provider update, add zipfs.jar into ext dir
Reviewed-by: alanb

! make/mkdemo/nio/zipfs/Makefile
! src/share/demo/nio/zipfs/Demo.java
- src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider
! src/share/demo/nio/zipfs/README.txt
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java
+ src/share/demo/nio/zipfs/src/META-INF/services/java.nio.file.spi.FileSystemProvider
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipDirectoryStream.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java
+ src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java
+ src/share/demo/zipfs
! test/demo/zipfs/Basic.java
! test/demo/zipfs/ZipFSTester.java

Changeset: 34f8b6669273
Author:    weijun
Date:      2010-12-07 09:51 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/34f8b6669273

6986825: policytool can not save file.
Reviewed-by: wetmore

! src/share/classes/sun/security/tools/policytool/PolicyTool.java

Changeset: 964eae6d1cab
Author:    mduigou
Date:      2010-12-06 19:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/964eae6d1cab

7004205: fixes handling of sane-gcc-compiler on 32-bit linux and solaris. Previously committed as 6998016 and 6998012
Reviewed-by: ohair, dholmes

! make/common/shared/Defs-linux.gmk
! make/common/shared/Defs-versions.gmk
! make/common/shared/Sanity.gmk

Changeset: e97a9a2892e2
Author:    mduigou
Date:      2010-12-06 19:40 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e97a9a2892e2

Merge


Changeset: 733ef59db5a9
Author:    darcy
Date:      2010-12-07 01:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/733ef59db5a9

6990094: ObjectInputStream cloneArray doesn't handle short[]
Reviewed-by: alanb, smarks, peterjones

! src/share/classes/java/io/ObjectInputStream.java
+ test/java/io/Serializable/cloneArray/CloneArray.java

Changeset: beeea65e79f4
Author:    weijun
Date:      2010-12-07 17:30 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/beeea65e79f4

6990370: FindBugs scan - Malicious code vulnerability Warnings in com.sun.jndi.ldap.*
Reviewed-by: xuelei

! src/share/classes/com/sun/jndi/ldap/BasicControl.java

Changeset: aeaadac45240
Author:    michaelm
Date:      2010-12-07 13:27 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/aeaadac45240

7005016: sqe test jhttp/HttpServer150013/HttpServer150013.java
Reviewed-by: chegar

! src/share/classes/sun/net/httpserver/Request.java
! src/share/classes/sun/net/httpserver/SSLStreams.java
! src/share/classes/sun/net/httpserver/ServerConfig.java
+ test/com/sun/net/httpserver/Test10.java

Changeset: 9e173410b4d5
Author:    michaelm
Date:      2010-12-07 13:29 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9e173410b4d5

Merge

- src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java

Changeset: 291128e77395
Author:    mullan
Date:      2010-12-08 10:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/291128e77395

6998860: Signed jar file verification is currently creating many extra new Sun providers.
Reviewed-by: mchung

! src/share/classes/sun/security/util/ManifestEntryVerifier.java

Changeset: acce526a49a7
Author:    mchung
Date:      2010-12-08 10:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/acce526a49a7

6977034: Thread.getState() very slow
Summary: Directly map the threadStatus value to Thread.State
Reviewed-by: emcmanus, dholmes

! src/share/classes/java/lang/Thread.java
! src/share/classes/sun/misc/VM.java

Changeset: 01b6d147db50
Author:    sherman
Date:      2010-12-08 12:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/01b6d147db50

6527572: (cs) Charset.forName can throw NullPointerException when testing bug level
Summary: fixed the race condition
Reviewed-by: alanb

! src/share/classes/java/nio/charset/Charset.java

Changeset: 956de70712e0
Author:    sherman
Date:      2010-12-08 12:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/956de70712e0

6415373: (cs) UnicodeEncoder emits BOM when there are no bytes to encode
Summary: no BOM output if no byte to encode
Reviewed-by: alanb

! src/share/classes/sun/nio/cs/UTF_32Coder.java
! src/share/classes/sun/nio/cs/UnicodeEncoder.java
+ test/sun/nio/cs/EncodingNothing.java

Changeset: 03513756704c
Author:    sherman
Date:      2010-12-08 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/03513756704c

5076980: (fmt) FormattableFlags specifies unsupported '^' format flag
Summary: replaced '^' with 'S' in spec
Reviewed-by: darcy

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

Changeset: 1bf378034d39
Author:    lancea
Date:      2010-12-09 13:01 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1bf378034d39

6659234: Incorrect check in SerialBlob.getBytes
Reviewed-by: darcy

! src/share/classes/javax/sql/rowset/serial/SerialBlob.java

Changeset: 79947a4ad7a1
Author:    chegar
Date:      2010-12-10 10:47 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/79947a4ad7a1

7004439: SCTP_SET_PEER_PRIMARY_ADDR throws SocketException on Linux
Summary: IPv4 addrs passed to SCTP_SET_PEER_PRIMARY_ADDR should not be converted to IPv4-mapped addrs
Reviewed-by: michaelm

! src/solaris/classes/sun/nio/ch/SctpNet.java
! src/solaris/native/sun/nio/ch/SctpNet.c
! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java

Changeset: 43ae1a1cc7a4
Author:    coffeys
Date:      2010-12-10 15:11 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/43ae1a1cc7a4

6998583: NativeSeedGenerator is making 8192 byte read requests from entropy pool on each init.
Reviewed-by: wetmore, andrew, vinnie

! src/share/classes/sun/security/provider/SeedGenerator.java
! src/windows/classes/sun/security/provider/NativeSeedGenerator.java
+ test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java

Changeset: 4a18d1bb21c3
Author:    lana
Date:      2010-12-12 15:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4a18d1bb21c3

Merge


Changeset: 8f0957d16c20
Author:    vinnie
Date:      2010-12-13 14:58 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8f0957d16c20

6799854: CodeSigner.hashCode() does not work with serialization
Reviewed-by: mullan

! src/share/classes/java/security/CodeSigner.java
! src/share/classes/java/security/Timestamp.java
! src/share/native/sun/security/ec/ECC_JNI.cpp
+ test/java/security/CodeSigner/Serialize.java
+ test/java/security/CodeSigner/cert_file

Changeset: 2d858fb6110d
Author:    vinnie
Date:      2010-12-13 15:07 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2d858fb6110d

Merge

- src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java

Changeset: 1740ad242f56
Author:    sherman
Date:      2010-12-13 14:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1740ad242f56

7003462: cannot read InputStream returned by java.util.ZipFile.getInputStream(ZipEntry)
Summary: The returned InflatedInputStream object should be kept in map streams
Reviewed-by: alanb

! src/share/classes/java/util/zip/ZipFile.java
+ test/java/util/zip/ZipFile/FinalizeInflater.java

Changeset: 78885e69c42c
Author:    darcy
Date:      2010-12-13 14:34 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/78885e69c42c

7006129: Project Coin: Annotation type to reduce varargs warnings
Reviewed-by: jjg, mcimadamore

! make/java/java/FILES_java.gmk
+ src/share/classes/java/lang/SafeVarargs.java

Changeset: 9cc67a600965
Author:    lana
Date:      2010-12-13 16:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9cc67a600965

Merge

- src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java

Changeset: 550a81304d04
Author:    lana
Date:      2010-12-20 21:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/550a81304d04

Merge

! make/common/shared/Defs-versions.gmk
! make/common/shared/Sanity.gmk
- src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java
- src/share/native/sun/font/layout/HebrewLigatureData.cpp
- src/share/native/sun/font/layout/HebrewShaping.cpp
- src/share/native/sun/font/layout/HebrewShaping.h

Changeset: 2dbd18b83bad
Author:    trims
Date:      2010-12-21 16:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2dbd18b83bad

Merge

- src/share/classes/java/dyn/BootstrapMethod.java
- src/share/classes/java/dyn/LinkagePermission.java
- src/share/classes/java/dyn/MethodHandleProvider.java
- src/share/classes/sun/dyn/JavaMethodHandle.java
- test/java/dyn/JavaDocExamples.java

Changeset: cbf9f3826c2d
Author:    igor
Date:      2010-11-30 09:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cbf9f3826c2d

Merge

- src/share/classes/sun/security/krb5/KrbKdcReq.java
- src/share/classes/sun/security/krb5/internal/TCPClient.java
- src/share/classes/sun/security/krb5/internal/UDPClient.java
- src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java

Changeset: 7fb84fe35a93
Author:    igor
Date:      2010-12-06 00:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7fb84fe35a93

Merge


Changeset: 22b7781ad25a
Author:    igor
Date:      2010-12-08 01:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/22b7781ad25a

Merge

- src/share/classes/sun/net/httpserver/SelectorCache.java

Changeset: e7972f7e82d1
Author:    herrick
Date:      2010-12-12 22:58 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e7972f7e82d1

Merge


Changeset: 1124ac162f32
Author:    herrick
Date:      2010-12-20 13:15 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1124ac162f32

Merge


Changeset: 36898b974d28
Author:    igor
Date:      2010-12-21 15:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/36898b974d28

Merge

- src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java
- src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java
- src/share/native/sun/font/layout/HebrewLigatureData.cpp
- src/share/native/sun/font/layout/HebrewShaping.cpp
- src/share/native/sun/font/layout/HebrewShaping.h

Changeset: 869190935eed
Author:    igor
Date:      2010-12-21 18:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/869190935eed

Merge

- src/share/classes/java/dyn/BootstrapMethod.java
- src/share/classes/java/dyn/LinkagePermission.java
- src/share/classes/java/dyn/MethodHandleProvider.java
- src/share/classes/sun/dyn/JavaMethodHandle.java
- test/java/dyn/JavaDocExamples.java

Changeset: 83480217896c
Author:    cl
Date:      2010-12-22 15:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/83480217896c

Added tag jdk7-b123 for changeset 869190935eed

! .hgtags


From zhengyu.gu at oracle.com  Mon Dec 27 11:46:51 2010
From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com)
Date: Mon, 27 Dec 2010 19:46:51 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20101227194655.6B6A5477B8@hg.openjdk.java.net>

Changeset: e0c969b97f66
Author:    zgu
Date:      2010-12-27 09:30 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e0c969b97f66

6975480: VS2010 says _STATIC_CPPLIB is deprecated, may need to change this usage
Summary: Disabled the warning message during compiling.
Reviewed-by: coleenp, dholmes

! make/windows/makefiles/compile.make

Changeset: dbf8dcf069d1
Author:    zgu
Date:      2010-12-27 09:56 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/dbf8dcf069d1

Merge

! make/windows/makefiles/compile.make


From john.coomes at oracle.com  Tue Dec 28 16:32:50 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 29 Dec 2010 00:32:50 +0000
Subject: hg: jdk7/hotspot-rt/langtools: 49 new changesets
Message-ID: <20101229003424.6F6F147809@hg.openjdk.java.net>

Changeset: fb79ba6eb2e1
Author:    cl
Date:      2010-11-22 14:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/fb79ba6eb2e1

Added tag jdk7-b119 for changeset 814561077c44

! .hgtags

Changeset: d53cf2e9ad6c
Author:    ohair
Date:      2010-12-03 19:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d53cf2e9ad6c

Merge

! .hgtags

Changeset: abaceae7c9f8
Author:    jjg
Date:      2010-11-17 15:07 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/abaceae7c9f8

7000973: isBogus needs to be called on the to-be-returned entry, not on the current entry
Reviewed-by: jjg
Contributed-by: jan.lahoda at oracle.com

! src/share/classes/com/sun/tools/javac/code/Scope.java

Changeset: 03177f49411d
Author:    jjg
Date:      2010-11-18 16:13 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/03177f49411d

6999438: remove support for exotic identifiers from JDK 7
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
- test/tools/javac/diags/examples/EmptyBytecodeIdent.java
- test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java
- test/tools/javac/diags/examples/UnclosedBytecodeIdent.java
- test/tools/javac/diags/examples/UnsupportedExoticID.java
! test/tools/javac/meth/InvokeDyn.java
! test/tools/javac/meth/InvokeDynTrans.java
! test/tools/javac/meth/InvokeDynTrans.out
- test/tools/javac/quid/QuotedIdent.java
- test/tools/javac/quid/QuotedIdent2.java
+ test/tools/javac/quid/T6999438.java
+ test/tools/javac/quid/T6999438.out

Changeset: 2536dedd897e
Author:    mcimadamore
Date:      2010-11-23 11:08 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2536dedd897e

6995200: JDK 7 compiler crashes when type-variable is inferred from expected primitive type
Summary: 15.12.2.8 should use boxing when expected type in assignment context is a primitive type
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/generics/inference/6638712/T6638712a.java
+ test/tools/javac/generics/inference/6995200/T6995200.java

Changeset: 285896f2227a
Author:    jjg
Date:      2010-11-23 13:32 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/285896f2227a

6942366: javadoc no longer inherits doc from sourcepath
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java
+ test/tools/javadoc/6942366/T6942366.java
+ test/tools/javadoc/6942366/Test.java
+ test/tools/javadoc/6942366/p/Base.java

Changeset: 79d0c48d361e
Author:    jjg
Date:      2010-11-23 15:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/79d0c48d361e

7002346: javap test relies on location of scratch directory
Reviewed-by: ksrini

! test/tools/javap/T6729471.java

Changeset: d44d6d8493ad
Author:    jjg
Date:      2010-11-29 10:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d44d6d8493ad

7003006: add option to list directory in deterministic order
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java

Changeset: c44234f680da
Author:    jjg
Date:      2010-11-29 14:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/c44234f680da

6900037: javac should warn if earlier -source is used and bootclasspath not set
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/Paths.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java
! test/tools/javac/6341866/T6341866.java
! test/tools/javac/ClassFileModifiers/MemberModifiers.java
+ test/tools/javac/T6900037.java
+ test/tools/javac/T6900037.out
! test/tools/javac/TryWithResources/PlainTry.java
! test/tools/javac/annotations/neg/Dep.java
! test/tools/javac/diags/examples/AnnotationsNotSupported.java
! test/tools/javac/diags/examples/AssertAsIdentifier.java
! test/tools/javac/diags/examples/DiamondNotSupported.java
! test/tools/javac/diags/examples/EnumAsIdentifier.java
! test/tools/javac/diags/examples/EnumsNotSupported.java
! test/tools/javac/diags/examples/Expected2.java
! test/tools/javac/diags/examples/ForeachNotSupported.java
! test/tools/javac/diags/examples/GenericsNotSupported.java
! test/tools/javac/diags/examples/MulticatchNotSupported.java
! test/tools/javac/diags/examples/NeitherConditionalSubtype.java
+ test/tools/javac/diags/examples/SourceNoBootclasspath.java
! test/tools/javac/diags/examples/StaticImportNotSupported.java
! test/tools/javac/diags/examples/StringSwitchNotSupported.java
! test/tools/javac/diags/examples/TryResourceNotSupported.java
! test/tools/javac/diags/examples/TryWithoutCatchOrFinally.java
! test/tools/javac/diags/examples/UnsupportedBinaryLiteral.java
! test/tools/javac/diags/examples/UnsupportedFpLit.java
! test/tools/javac/diags/examples/UnsupportedUnderscoreLiteral.java
! test/tools/javac/diags/examples/VarargsNotSupported.java
! test/tools/javac/enum/6384542/T6384542.java
! test/tools/javac/enum/6384542/T6384542a.java
! test/tools/javac/literals/BadBinaryLiterals.java
! test/tools/javac/literals/BadUnderscoreLiterals.java
! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java
! test/tools/javac/varargs/warning/Warn1.java

Changeset: bcbc86cc5b31
Author:    jjg
Date:      2010-11-30 09:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/bcbc86cc5b31

7003477: Paths.isDefaultBootClassPath needs to be public
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/file/Paths.java

Changeset: 1bf969e9792f
Author:    lana
Date:      2010-12-06 20:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/1bf969e9792f

Merge

- test/tools/javac/diags/examples/EmptyBytecodeIdent.java
- test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java
- test/tools/javac/diags/examples/UnclosedBytecodeIdent.java
- test/tools/javac/diags/examples/UnsupportedExoticID.java
- test/tools/javac/quid/QuotedIdent.java
- test/tools/javac/quid/QuotedIdent2.java

Changeset: 11e7b4c0476e
Author:    katleman
Date:      2010-12-09 21:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/11e7b4c0476e

Added tag jdk7-b121 for changeset 1bf969e9792f

! .hgtags

Changeset: 9968ce958706
Author:    cl
Date:      2010-12-16 18:18 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/9968ce958706

Added tag jdk7-b122 for changeset 11e7b4c0476e

! .hgtags

Changeset: 4f086529d05c
Author:    mfang
Date:      2010-12-03 20:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4f086529d05c

6522789: [zh_CN] translation of "enclosing class" in doclet is incorrect
Reviewed-by: yhuang

! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties

Changeset: d9deecf9181b
Author:    mfang
Date:      2010-12-05 18:18 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d9deecf9181b

Merge


Changeset: a0331c79cea9
Author:    ohair
Date:      2010-12-15 15:30 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/a0331c79cea9

Merge


Changeset: 98570f7ba610
Author:    ohair
Date:      2010-12-16 19:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/98570f7ba610

Merge


Changeset: 90af8d87741f
Author:    bpatel
Date:      2010-12-01 11:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/90af8d87741f

6851834: Javadoc doclet needs a structured approach to generate the output HTML.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.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/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.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/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.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/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
- src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.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/TreeWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java
! test/com/sun/javadoc/AccessH1/AccessH1.java
! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java
! test/com/sun/javadoc/AccessSummary/AccessSummary.java
! test/com/sun/javadoc/AuthorDD/AuthorDD.java
! test/com/sun/javadoc/JavascriptWinTitle/JavascriptWinTitle.java
! test/com/sun/javadoc/MetaTag/MetaTag.java
! test/com/sun/javadoc/ValidHtml/ValidHtml.java
! test/com/sun/javadoc/VersionNumber/VersionNumber.java
! test/com/sun/javadoc/WindowTitles/WindowTitles.java
! test/com/sun/javadoc/constantValues/TestConstantValuesDriver.java
! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java
! test/com/sun/javadoc/testClassTree/TestClassTree.java
! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java
! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java
! test/com/sun/javadoc/testDocRootInlineTag/TestDocRootInlineTag.java
! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java
! test/com/sun/javadoc/testHeadings/TestHeadings.java
! test/com/sun/javadoc/testHelpOption/TestHelpOption.java
! test/com/sun/javadoc/testHref/TestHref.java
! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
+ test/com/sun/javadoc/testHtmlDocument/TestHtmlDocument.java
+ test/com/sun/javadoc/testHtmlDocument/testLink.html
+ test/com/sun/javadoc/testHtmlDocument/testMarkup.html
! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java
! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java
! test/com/sun/javadoc/testHtmlTag/TestHtmlTag.java
! test/com/sun/javadoc/testIndex/TestIndex.java
! test/com/sun/javadoc/testInlineLinkLabel/TestInlineLinkLabel.java
! test/com/sun/javadoc/testInterface/TestInterface.java
! test/com/sun/javadoc/testJavascript/TestJavascript.java
! test/com/sun/javadoc/testLinkOption/TestLinkOption.java
! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java
! test/com/sun/javadoc/testLinkToSerialForm/TestLinkToSerialForm.java
! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java
! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java
! test/com/sun/javadoc/testNavagation/TestNavagation.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.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/testPackagePage/TestPackagePage.java
! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java
! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java
! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java
! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java
! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java
! test/com/sun/javadoc/testStylesheet/TestStylesheet.java
! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java
! test/com/sun/javadoc/testSuperclassInSerialForm/TestSuperClassInSerialForm.java
! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java
! test/com/sun/javadoc/testTaglets/TestTaglets.java
! test/com/sun/javadoc/testTaglets/taglets/Foo.java
! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java
! test/com/sun/javadoc/testThrowsTag/TestThrowsTag.java
! test/com/sun/javadoc/testTitleInHref/TestTitleInHref.java
! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java
! test/com/sun/javadoc/testUnnamedPackage/TestUnnamedPackage.java
! test/com/sun/javadoc/testValueTag/TestValueTag.java
! test/com/sun/javadoc/testWarnings/TestWarnings.java

Changeset: 7e3e9f6d013f
Author:    jjg
Date:      2010-12-02 16:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/7e3e9f6d013f

7004029: intermittent failures compiling pack200
Summary: remove "bogus" entries from star-import scopes
Reviewed-by: mcimadamore
Contributed-by: per.bothner at oracle.com

! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/scope/HashCollisionTest.java
+ test/tools/javac/scope/StarImportTest.java

Changeset: 28566c763dad
Author:    jjg
Date:      2010-12-02 16:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/28566c763dad

Merge

- src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java

Changeset: 9359f4222545
Author:    mcimadamore
Date:      2010-12-03 16:31 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/9359f4222545

6956758: NPE in com.sun.tools.javac.code.Symbol - isSubClass
Summary: Use of TransTypes.cast() instead of TransTypes.coerce() causes NPE in Lower
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/generics/6956758/T6956758neg.java
+ test/tools/javac/generics/6956758/T6956758neg.out
+ test/tools/javac/generics/6956758/T6956758pos.java

Changeset: aa6605d883dc
Author:    mcimadamore
Date:      2010-12-03 16:32 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/aa6605d883dc

7002837: Diamond: javac generates diamond inference errors when in 'finder' mode
Summary: Javac should disable error messages when analyzing instance creation expression in 'diamond finder' mode
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/generics/diamond/7002837/T7002837.java

Changeset: 91b4f44c9742
Author:    jjh
Date:      2010-12-03 13:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/91b4f44c9742

6990209: JCK7-compiler lang/ICLS/icls006/icls00603/icls00603a.html#icls00603src test fails.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java

Changeset: d53b87e07b13
Author:    lana
Date:      2010-12-05 15:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d53b87e07b13

Merge


Changeset: 5fb14e67c371
Author:    mcimadamore
Date:      2010-12-06 11:49 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/5fb14e67c371

7003744: Compiler error concerning final variables
Summary: Flow analysis does not cleanup init/uninint bit masks after for-loop
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/util/Bits.java
+ test/tools/javac/DefiniteAssignment/7003744/T7003744a.java
+ test/tools/javac/DefiniteAssignment/7003744/T7003744b.java

Changeset: 56f59723fddf
Author:    mcimadamore
Date:      2010-12-06 11:50 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/56f59723fddf

7002070: If catch clause has an incompatible type, error pointer points to first exception type in list
Summary: Attribution should check each component of a disjunctive type separately, rather than checking the corresponding lub()
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/multicatch/Neg06.java
+ test/tools/javac/multicatch/Neg06.out

Changeset: 536ee9f126b1
Author:    mcimadamore
Date:      2010-12-06 11:51 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/536ee9f126b1

5088429: varargs overloading problem
Summary: compiler implementation for overload resolution w/ varargs method does not match JLS
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/varargs/5088429/T5088429Neg01.java
+ test/tools/javac/varargs/5088429/T5088429Neg01.out
+ test/tools/javac/varargs/5088429/T5088429Neg02.java
+ test/tools/javac/varargs/5088429/T5088429Neg02.out
+ test/tools/javac/varargs/5088429/T5088429Pos01.java
+ test/tools/javac/varargs/5088429/T5088429Pos02.java

Changeset: 3c32c90031fd
Author:    jjg
Date:      2010-12-07 14:13 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/3c32c90031fd

6999210: javac should be able to warn of anomalous conditions in classfiles
Reviewed-by: mcimadamore, darcy

! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
+ test/tools/javac/T6999210.java
! test/tools/javac/annotations/6214965/T6214965.out
! test/tools/javac/annotations/6365854/test1.out
! test/tools/javac/annotations/6365854/test2.out
! test/tools/javac/diags/examples.not-yet.txt

Changeset: acb02e1d5119
Author:    jjg
Date:      2010-12-08 13:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/acb02e1d5119

7004698: javap does not output CharacterRangeTable attributes correctly
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javap/AttributeWriter.java
+ test/tools/javap/T7004698.java

Changeset: 23fc45d3a572
Author:    darcy
Date:      2010-12-08 21:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/23fc45d3a572

7003550: Loosen modeling requirements for annotation processing erroneous code
Reviewed-by: jjg

! src/share/classes/javax/lang/model/element/package-info.java

Changeset: 5ef88773462b
Author:    mcimadamore
Date:      2010-12-09 15:50 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/5ef88773462b

7005095: Cast: compile reject sensible cast from final class to interface
Summary: a previous fix to cast conversion has made the compiler too strict w.r.t. final cast
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/7005095/T7005095neg.java
+ test/tools/javac/cast/7005095/T7005095neg.out
+ test/tools/javac/cast/7005095/T7005095pos.java

Changeset: 1d625fbe6c22
Author:    mcimadamore
Date:      2010-12-09 15:50 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/1d625fbe6c22

6476118: compiler bug causes runtime ClassCastException for generics overloading
Summary: compiler allows bridge methods to override unrelated method
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/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/6476118/T6476118a.java
+ test/tools/javac/generics/6476118/T6476118a.out
+ test/tools/javac/generics/6476118/T6476118b.java
+ test/tools/javac/generics/6476118/T6476118b.out
+ test/tools/javac/generics/6476118/T6476118c.java
+ test/tools/javac/generics/6476118/T6476118c.out
+ test/tools/javac/generics/6476118/T6476118d.java

Changeset: e3df8d7a9752
Author:    mcimadamore
Date:      2010-12-09 15:50 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/e3df8d7a9752

7005371: Multicatch: assertion error while generating LocalVariableTypeTable attribute
Summary: compiler crashes with assertion error if '-g' option is passed and source contains multicatch
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
+ test/tools/javac/multicatch/7005371/SubTest.java
+ test/tools/javac/multicatch/7005371/T7005371.java

Changeset: bcf44475aeee
Author:    jjg
Date:      2010-12-09 08:24 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/bcf44475aeee

4917091: javac rejects array over 128 in length
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/4917091/Test255.java
+ test/tools/javac/4917091/Test256a.java
+ test/tools/javac/4917091/Test256a.out
+ test/tools/javac/4917091/Test256b.java
+ test/tools/javac/4917091/Test256b.out

Changeset: 90914ac50868
Author:    jjg
Date:      2010-12-09 08:48 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/90914ac50868

6985202: no access to doc comments from Tree API
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/Trees.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
+ test/tools/javac/api/TestDocComments.java

Changeset: 4dd1c0176d81
Author:    jjg
Date:      2010-12-09 18:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4dd1c0176d81

7005856: avoid name clash for langtools when building on MacOS
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java

Changeset: 65820d0d4a97
Author:    jjg
Date:      2010-12-09 19:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/65820d0d4a97

6986242: cut-n-paste error in javadoc for Trees.instance(ProcessingEnvironment)
Reviewed-by: darcy

! src/share/classes/com/sun/source/util/Trees.java

Changeset: 2ca5866a8dfb
Author:    mcimadamore
Date:      2010-12-10 15:23 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2ca5866a8dfb

7005671: Regression: compiler accepts invalid cast from X[] to primitive array
Summary: regression in type conversion after 292 changes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/7005671/T7005671.java
+ test/tools/javac/cast/7005671/T7005671.out

Changeset: b1c98bfd4709
Author:    mcimadamore
Date:      2010-12-10 15:24 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/b1c98bfd4709

6199075: Unambiguous varargs method calls flagged as ambiguous
Summary: javac does not implement overload resolution w.r.t. varargs methods as described in the JLS
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/varargs/6199075/T6199075.java

Changeset: 8ec3a824f925
Author:    jjg
Date:      2010-12-10 07:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/8ec3a824f925

6504896: TreeMaker.Literal(Object) does not support Booleans
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
+ test/tools/javac/tree/MakeLiteralTest.java

Changeset: 878c8f760ded
Author:    jjg
Date:      2010-12-12 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/878c8f760ded

6990134: minor (but red) findbugs warnings
Reviewed-by: mcimadamore

+ src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java
- src/share/classes/com/sun/tools/apt/main/JavaCompiler.java
! src/share/classes/com/sun/tools/apt/main/Main.java
! src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: fe43a7efd273
Author:    lana
Date:      2010-12-12 15:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/fe43a7efd273

Merge


Changeset: dd9b5f767559
Author:    lana
Date:      2010-12-12 21:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/dd9b5f767559

Merge

- src/share/classes/com/sun/tools/apt/main/JavaCompiler.java

Changeset: 2199365892b1
Author:    mcimadamore
Date:      2010-12-13 14:56 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2199365892b1

7006109: Add test library to simplify the task of writing automated type-system tests
Summary: Types.java needs to be more stress-tested
Reviewed-by: jjg

+ test/tools/javac/types/BoxingConversionTest.java
+ test/tools/javac/types/CastTest.java
+ test/tools/javac/types/PrimitiveConversionTest.java
+ test/tools/javac/types/TypeHarness.java

Changeset: ffbf2b2a8611
Author:    bpatel
Date:      2010-12-13 13:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/ffbf2b2a8611

7006270: Several javadoc regression tests are failing on windows
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! test/com/sun/javadoc/testHtmlDocument/TestHtmlDocument.java

Changeset: 2f2ead61db06
Author:    bpatel
Date:      2010-12-13 14:08 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2f2ead61db06

Merge

- src/share/classes/com/sun/tools/apt/main/JavaCompiler.java

Changeset: 7b99f98b3035
Author:    mcimadamore
Date:      2010-12-13 15:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/7b99f98b3035

6993978: Project Coin: Compiler support of annotation to reduce varargs warnings
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! 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/Check.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/Warner.java
! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/RunExamples.java
+ test/tools/javac/diags/examples/TrustMeOnNonVarargsMeth.java
+ test/tools/javac/diags/examples/TrustMeOnReifiableVarargsParam.java
+ test/tools/javac/diags/examples/TrustMeOnVirtualMethod.java
! test/tools/javac/diags/examples/UncheckedGenericArrayCreation.java
+ test/tools/javac/diags/examples/UnsafeUseOfVarargsParam.java
- test/tools/javac/diags/examples/VarargsFilename.java
- test/tools/javac/diags/examples/VarargsFilenameAdditional.java
! test/tools/javac/diags/examples/VarargsNonReifiableType.java
- test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java
- test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java
- test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java
- test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java
- test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java
! test/tools/javac/varargs/6730476/T6730476a.java
! test/tools/javac/varargs/6806876/T6806876.out
+ test/tools/javac/varargs/6993978/T6993978neg.java
+ test/tools/javac/varargs/6993978/T6993978neg.out
! test/tools/javac/varargs/warning/Warn4.java
+ test/tools/javac/varargs/warning/Warn5.java

Changeset: a3b5b531542a
Author:    lana
Date:      2010-12-20 21:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/a3b5b531542a

Merge

- src/share/classes/com/sun/tools/apt/main/JavaCompiler.java
- src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java
- test/tools/javac/diags/examples/VarargsFilename.java
- test/tools/javac/diags/examples/VarargsFilenameAdditional.java
- test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java
- test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java
- test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java
- test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java
- test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java

Changeset: 659417e931fe
Author:    cl
Date:      2010-12-22 15:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/659417e931fe

Added tag jdk7-b123 for changeset a3b5b531542a

! .hgtags


From coleen.phillimore at oracle.com  Wed Dec 29 15:11:04 2010
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 29 Dec 2010 18:11:04 -0500
Subject: Request for review (and comments) 6302804: Hotspot VM dies
	ungraceful death when C heap is exhausted in various places.
In-Reply-To: <4D129B78.20505@oracle.com>
References: <4D0FD48E.4080009@oracle.com> <4D101D13.4090100@oracle.com>
	<4D1287A2.6060006@oracle.com> <4D128FC0.9050306@oracle.com>
	<4D129B78.20505@oracle.com>
Message-ID: <4D1BC008.4090603@oracle.com>

Summary: enhance the error reporting mechanism to help user to fix the 
problem rather than making it look like a VM error.

I've incorporated the comments that I've received and have a new webrev.

open webrev at http://cr.openjdk.java.net/~coleenp/6302804_2/
bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804

Thanks,
Coleen

On 12/22/2010 7:44 PM, Vladimir Kozlov wrote:
> Sorry for noise - it was JDK bug.
>
> I found that the problem was with previous JDK with build > 99:
> 6994413: JDK_GetVersionInfo0 only expects a two digit build number
>
> This bug was fixed in b118 JDK.
>
> So when we used before jdk7-b107 for JPRT it had this bug.
>
> Latest JPRT builds (which uses latest jdk) does not have this problem:
>
> # JRE version: 7.0-b122
> # Java VM: OpenJDK 64-Bit Server VM 
> (20.0-b04-internal-201012221004.ct232829.7007377-fastdebug compiled 
> mode solaris-sparc compressed oops)
>
> Thanks,
> Vladimir
>
>
> Coleen Phillimore wrote:
>> On 12/22/2010 6:20 PM, Vladimir Kozlov wrote:
>>> Coleen,
>>>
>>> Could you also fix "JRE version: 7.0" output to print full JRE 
>>> version (as with -version) since you are touching this code?
>> Actually, I tried to do this when I implemented this the first time.  
>> If I remember correctly, most of the text from -version comes from 
>> the JDK and the only bit of the version I could find from the VM was 
>> in vm_version(), which was just this number.  Because it was in error 
>> handling, I didn't want to add a callback to the jdk (or call one if 
>> it already existed).
>>
>> Coleen
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> Vladimir Kozlov wrote:
>>>> Coleen,
>>>>
>>>> Could you use "Out of swap space" in "No swap to commit thread stack"?
>>>>
>>>> With these changes next output:
>>>>
>>>> #
>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>> #
>>>> # java.lang.OutOfMemoryError: requested 32764 bytes for 
>>>> ChunkPool::allocate. Out of swap space?
>>>> #
>>>> #  Internal Error 
>>>> (C:\temp\jprt\P1\B\213124.ap31282\source\src\share\vm\memory\allocation.cpp:181), 
>>>> pid=17396, tid=14008
>>>> #  Error: ChunkPool::allocate
>>>> #
>>>> # JRE version: 7.0
>>>> # Java VM: OpenJDK Server VM 
>>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>>>> mixed mode windows-x86 )
>>>> # If you would like to submit a bug report, please visit:
>>>> #   http://java.sun.com/webapps/bugreport/crash.jsp
>>>> #
>>>>
>>>> Will be converted to next. Right?
>>>>
>>>> # There is insufficient native memory for the Java Runtime 
>>>> Environment to continue.
>>>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>>>> #
>>>> # JRE version: 7.0
>>>> # Java VM: OpenJDK Server VM 
>>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>>>> mixed mode windows-x86 )
>>>>
>>>> Could you swap next lines to be consistent with non oom errors?:
>>>>
>>>>  325     if (_id != oom_error) {
>>>>  326       st->print_cr("#");
>>>>
>>>> to:
>>>>
>>>>  325     st->print_cr("#");
>>>>  326     if (_id != oom_error) {
>>>>
>>>>
>>>> Instead of next:
>>>>
>>>> # There is insufficient native memory for the Java Runtime 
>>>> Environment to continue.
>>>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>>>>
>>>> how about this?:
>>>>
>>>> # There is insufficient native memory for the Java Runtime 
>>>> Environment to continue:
>>>> # malloc failed to allocate XXX bytes for mmm.
>>>>
>>>>
>>>> Also may be add comma at the end of solution lines.
>>>> An other solution is to use 64bit VM on 64bit OS.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> coleen phillimore wrote:
>>>>> Summary: enhance the error reporting mechanism to direct user to 
>>>>> fix the problem rather than making it look like a VM error.
>>>>>
>>>>> I changed the error reporting so that out of swap and out of 
>>>>> native (C heap) memory doesn't look like a VM assert or look like 
>>>>> a java.lang.OutOfMemoryError exception that someone could catch.  
>>>>> The suggested new wording is in the bug link Evaluation section.  
>>>>> I'm open to rewording if people have strong preferences.
>>>>> Also, if solaris runs out of swap space (generally by filling up 
>>>>> /tmp), access to thread stacks generate a bus error with ENOMEM 
>>>>> errno.  I can check for this in the solaris signal handler and 
>>>>> give the out of C heap message.  I couldn't get Linux or windows 
>>>>> to fail the same way, so didn't apply similar changes there.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6302804/
>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>
>>>>
>>


From coleen.phillimore at oracle.com  Wed Dec 29 15:18:31 2010
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 29 Dec 2010 18:18:31 -0500
Subject: Request for review (S) 4926272: methodOopDesc::method_from_bcp is
	unsafe
Message-ID: <4D1BC1C7.9080502@oracle.com>

Summary: Instead of using GC to find the block start, scan backward in 
memory to known contents in the constMethodOop

open webrev at http://cr.openjdk.java.net/~coleenp/4926272/
bug link at http://bugs.sun.com/view_bug.do?bug_id=4926272

Tested on 32 and 64 bit platforms with the test cases that reliably failed.

Thanks,
Coleen


From coleen.phillimore at oracle.com  Wed Dec 29 15:22:44 2010
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 29 Dec 2010 23:22:44 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 8 new changesets
Message-ID: <20101229232257.D784147840@hg.openjdk.java.net>

Changeset: 08b76f57574b
Author:    cl
Date:      2010-12-22 15:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/08b76f57574b

Added tag jdk7-b123 for changeset 9669f9b28410

! .hgtags

Changeset: cd8189d84e92
Author:    trims
Date:      2010-12-22 19:20 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/cd8189d84e92

Added tag hs20-b04 for changeset 9669f9b28410

! .hgtags

Changeset: b03260081e9b
Author:    johnc
Date:      2010-12-17 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b03260081e9b

7006113: G1: Initialize ReferenceProcessor::_is_alive_non_header field
Summary: Initialize the _is_alive_non_header field of G1's reference processor with an instance of the G1CMIsAliveClosure. This will stop adding reference objects with live referents to the discovered reference lists unnecessarily.
Reviewed-by: tonyp, ysr, jwilhelm, brutisso

! 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

Changeset: 74ee0db180fa
Author:    ysr
Date:      2010-12-17 23:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/74ee0db180fa

6807801: CMS: could save/restore fewer header words during scavenge
Summary: Age bits need not enter the mark-word preservation calculus; also affected, in addition to CMS, per CR synopsis above, were ParNew (but not DefNew), ParallelScavenge and G1, albeit to a lesser degree than CMS.
Reviewed-by: tonyp, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/defNewGeneration.hpp
! src/share/vm/oops/markOop.inline.hpp

Changeset: 7c5250dbd584
Author:    tonyp
Date:      2010-12-19 20:57 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7c5250dbd584

6896624: G1: hotspot:::gc and hotspot:::mem-pool-gc probes are not fired
Summary: Fire the gc-begin and gc-end probes for G1.
Reviewed-by: kamg, ysr, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/shared/vmGCOperations.hpp

Changeset: 9026f05dc736
Author:    johnc
Date:      2010-12-23 12:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9026f05dc736

Merge


Changeset: 5ef9917b908d
Author:    trims
Date:      2010-12-24 07:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5ef9917b908d

7008759: Bump the HS20 build number to 05
Summary: Update the HS20 build number to 05
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 06e4b9c9db76
Author:    coleenp
Date:      2010-12-28 09:54 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/06e4b9c9db76

Merge



From vladimir.kozlov at oracle.com  Wed Dec 29 15:57:08 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 29 Dec 2010 15:57:08 -0800
Subject: Request for review (and comments) 6302804: Hotspot VM dies
	ungraceful death when C heap is exhausted in various places.
In-Reply-To: <4D1BC008.4090603@oracle.com>
References: <4D0FD48E.4080009@oracle.com>
	<4D101D13.4090100@oracle.com>	<4D1287A2.6060006@oracle.com>
	<4D128FC0.9050306@oracle.com>	<4D129B78.20505@oracle.com>
	<4D1BC008.4090603@oracle.com>
Message-ID: <4D1BCAD4.2000308@oracle.com>

Coleen,

Everything looks good.
One thing, in solutions instead of "the 4g process size" should be something general since on windows we have only 2Gb.
May be  "In 32 bit mode, the addressable memory size limit was hit"
                                     ^ I am not sure about my English here.

Thanks,
Vladimir

Coleen Phillimore wrote:
> Summary: enhance the error reporting mechanism to help user to fix the 
> problem rather than making it look like a VM error.
> 
> I've incorporated the comments that I've received and have a new webrev.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/6302804_2/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804
> 
> Thanks,
> Coleen
> 
> On 12/22/2010 7:44 PM, Vladimir Kozlov wrote:
>> Sorry for noise - it was JDK bug.
>>
>> I found that the problem was with previous JDK with build > 99:
>> 6994413: JDK_GetVersionInfo0 only expects a two digit build number
>>
>> This bug was fixed in b118 JDK.
>>
>> So when we used before jdk7-b107 for JPRT it had this bug.
>>
>> Latest JPRT builds (which uses latest jdk) does not have this problem:
>>
>> # JRE version: 7.0-b122
>> # Java VM: OpenJDK 64-Bit Server VM 
>> (20.0-b04-internal-201012221004.ct232829.7007377-fastdebug compiled 
>> mode solaris-sparc compressed oops)
>>
>> Thanks,
>> Vladimir
>>
>>
>> Coleen Phillimore wrote:
>>> On 12/22/2010 6:20 PM, Vladimir Kozlov wrote:
>>>> Coleen,
>>>>
>>>> Could you also fix "JRE version: 7.0" output to print full JRE 
>>>> version (as with -version) since you are touching this code?
>>> Actually, I tried to do this when I implemented this the first time.  
>>> If I remember correctly, most of the text from -version comes from 
>>> the JDK and the only bit of the version I could find from the VM was 
>>> in vm_version(), which was just this number.  Because it was in error 
>>> handling, I didn't want to add a callback to the jdk (or call one if 
>>> it already existed).
>>>
>>> Coleen
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> Vladimir Kozlov wrote:
>>>>> Coleen,
>>>>>
>>>>> Could you use "Out of swap space" in "No swap to commit thread stack"?
>>>>>
>>>>> With these changes next output:
>>>>>
>>>>> #
>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>> #
>>>>> # java.lang.OutOfMemoryError: requested 32764 bytes for 
>>>>> ChunkPool::allocate. Out of swap space?
>>>>> #
>>>>> #  Internal Error 
>>>>> (C:\temp\jprt\P1\B\213124.ap31282\source\src\share\vm\memory\allocation.cpp:181), 
>>>>> pid=17396, tid=14008
>>>>> #  Error: ChunkPool::allocate
>>>>> #
>>>>> # JRE version: 7.0
>>>>> # Java VM: OpenJDK Server VM 
>>>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>>>>> mixed mode windows-x86 )
>>>>> # If you would like to submit a bug report, please visit:
>>>>> #   http://java.sun.com/webapps/bugreport/crash.jsp
>>>>> #
>>>>>
>>>>> Will be converted to next. Right?
>>>>>
>>>>> # There is insufficient native memory for the Java Runtime 
>>>>> Environment to continue.
>>>>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>>>>> #
>>>>> # JRE version: 7.0
>>>>> # Java VM: OpenJDK Server VM 
>>>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>>>>> mixed mode windows-x86 )
>>>>>
>>>>> Could you swap next lines to be consistent with non oom errors?:
>>>>>
>>>>>  325     if (_id != oom_error) {
>>>>>  326       st->print_cr("#");
>>>>>
>>>>> to:
>>>>>
>>>>>  325     st->print_cr("#");
>>>>>  326     if (_id != oom_error) {
>>>>>
>>>>>
>>>>> Instead of next:
>>>>>
>>>>> # There is insufficient native memory for the Java Runtime 
>>>>> Environment to continue.
>>>>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>>>>>
>>>>> how about this?:
>>>>>
>>>>> # There is insufficient native memory for the Java Runtime 
>>>>> Environment to continue:
>>>>> # malloc failed to allocate XXX bytes for mmm.
>>>>>
>>>>>
>>>>> Also may be add comma at the end of solution lines.
>>>>> An other solution is to use 64bit VM on 64bit OS.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> coleen phillimore wrote:
>>>>>> Summary: enhance the error reporting mechanism to direct user to 
>>>>>> fix the problem rather than making it look like a VM error.
>>>>>>
>>>>>> I changed the error reporting so that out of swap and out of 
>>>>>> native (C heap) memory doesn't look like a VM assert or look like 
>>>>>> a java.lang.OutOfMemoryError exception that someone could catch.  
>>>>>> The suggested new wording is in the bug link Evaluation section.  
>>>>>> I'm open to rewording if people have strong preferences.
>>>>>> Also, if solaris runs out of swap space (generally by filling up 
>>>>>> /tmp), access to thread stacks generate a bus error with ENOMEM 
>>>>>> errno.  I can check for this in the solaris signal handler and 
>>>>>> give the out of C heap message.  I couldn't get Linux or windows 
>>>>>> to fail the same way, so didn't apply similar changes there.
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6302804/
>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>
>>>>>
>>>
> 

From kevin.walls at oracle.com  Fri Dec 31 03:30:45 2010
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 31 Dec 2010 11:30:45 +0000
Subject: Request for review (and comments) 6302804: Hotspot VM dies
	ungraceful death when C heap is exhausted in various places.
In-Reply-To: <4D1BCAD4.2000308@oracle.com>
References: <4D0FD48E.4080009@oracle.com>	<4D101D13.4090100@oracle.com>	<4D1287A2.6060006@oracle.com>	<4D128FC0.9050306@oracle.com>	<4D129B78.20505@oracle.com>	<4D1BC008.4090603@oracle.com>
	<4D1BCAD4.2000308@oracle.com>
Message-ID: <4D1DBEE5.6020209@oracle.com>


"addressable" is fine in English 8-), but perhaps simpler to say just 
"the process size limit" without stating 4g.


On 29/12/2010 23:57, Vladimir Kozlov wrote:
> Coleen,
>
> Everything looks good.
> One thing, in solutions instead of "the 4g process size" should be 
> something general since on windows we have only 2Gb.
> May be  "In 32 bit mode, the addressable memory size limit was hit"
>                                     ^ I am not sure about my English 
> here.
>
> Thanks,
> Vladimir
>
> Coleen Phillimore wrote:
>> Summary: enhance the error reporting mechanism to help user to fix 
>> the problem rather than making it look like a VM error.
>>
>> I've incorporated the comments that I've received and have a new webrev.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6302804_2/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804
>>
>> Thanks,
>> Coleen
>>
>> On 12/22/2010 7:44 PM, Vladimir Kozlov wrote:
>>> Sorry for noise - it was JDK bug.
>>>
>>> I found that the problem was with previous JDK with build > 99:
>>> 6994413: JDK_GetVersionInfo0 only expects a two digit build number
>>>
>>> This bug was fixed in b118 JDK.
>>>
>>> So when we used before jdk7-b107 for JPRT it had this bug.
>>>
>>> Latest JPRT builds (which uses latest jdk) does not have this problem:
>>>
>>> # JRE version: 7.0-b122
>>> # Java VM: OpenJDK 64-Bit Server VM 
>>> (20.0-b04-internal-201012221004.ct232829.7007377-fastdebug compiled 
>>> mode solaris-sparc compressed oops)
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>
>>> Coleen Phillimore wrote:
>>>> On 12/22/2010 6:20 PM, Vladimir Kozlov wrote:
>>>>> Coleen,
>>>>>
>>>>> Could you also fix "JRE version: 7.0" output to print full JRE 
>>>>> version (as with -version) since you are touching this code?
>>>> Actually, I tried to do this when I implemented this the first 
>>>> time.  If I remember correctly, most of the text from -version 
>>>> comes from the JDK and the only bit of the version I could find 
>>>> from the VM was in vm_version(), which was just this number.  
>>>> Because it was in error handling, I didn't want to add a callback 
>>>> to the jdk (or call one if it already existed).
>>>>
>>>> Coleen
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> Vladimir Kozlov wrote:
>>>>>> Coleen,
>>>>>>
>>>>>> Could you use "Out of swap space" in "No swap to commit thread 
>>>>>> stack"?
>>>>>>
>>>>>> With these changes next output:
>>>>>>
>>>>>> #
>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>> #
>>>>>> # java.lang.OutOfMemoryError: requested 32764 bytes for 
>>>>>> ChunkPool::allocate. Out of swap space?
>>>>>> #
>>>>>> #  Internal Error 
>>>>>> (C:\temp\jprt\P1\B\213124.ap31282\source\src\share\vm\memory\allocation.cpp:181), 
>>>>>> pid=17396, tid=14008
>>>>>> #  Error: ChunkPool::allocate
>>>>>> #
>>>>>> # JRE version: 7.0
>>>>>> # Java VM: OpenJDK Server VM 
>>>>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>>>>>> mixed mode windows-x86 )
>>>>>> # If you would like to submit a bug report, please visit:
>>>>>> #   http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>> #
>>>>>>
>>>>>> Will be converted to next. Right?
>>>>>>
>>>>>> # There is insufficient native memory for the Java Runtime 
>>>>>> Environment to continue.
>>>>>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>>>>>> #
>>>>>> # JRE version: 7.0
>>>>>> # Java VM: OpenJDK Server VM 
>>>>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug 
>>>>>> mixed mode windows-x86 )
>>>>>>
>>>>>> Could you swap next lines to be consistent with non oom errors?:
>>>>>>
>>>>>>  325     if (_id != oom_error) {
>>>>>>  326       st->print_cr("#");
>>>>>>
>>>>>> to:
>>>>>>
>>>>>>  325     st->print_cr("#");
>>>>>>  326     if (_id != oom_error) {
>>>>>>
>>>>>>
>>>>>> Instead of next:
>>>>>>
>>>>>> # There is insufficient native memory for the Java Runtime 
>>>>>> Environment to continue.
>>>>>> # Attempting to allocate XXX bytes for mmm. malloc failed.
>>>>>>
>>>>>> how about this?:
>>>>>>
>>>>>> # There is insufficient native memory for the Java Runtime 
>>>>>> Environment to continue:
>>>>>> # malloc failed to allocate XXX bytes for mmm.
>>>>>>
>>>>>>
>>>>>> Also may be add comma at the end of solution lines.
>>>>>> An other solution is to use 64bit VM on 64bit OS.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> coleen phillimore wrote:
>>>>>>> Summary: enhance the error reporting mechanism to direct user to 
>>>>>>> fix the problem rather than making it look like a VM error.
>>>>>>>
>>>>>>> I changed the error reporting so that out of swap and out of 
>>>>>>> native (C heap) memory doesn't look like a VM assert or look 
>>>>>>> like a java.lang.OutOfMemoryError exception that someone could 
>>>>>>> catch.  The suggested new wording is in the bug link Evaluation 
>>>>>>> section.  I'm open to rewording if people have strong preferences.
>>>>>>> Also, if solaris runs out of swap space (generally by filling up 
>>>>>>> /tmp), access to thread stacks generate a bus error with ENOMEM 
>>>>>>> errno.  I can check for this in the solaris signal handler and 
>>>>>>> give the out of C heap message.  I couldn't get Linux or windows 
>>>>>>> to fail the same way, so didn't apply similar changes there.
>>>>>>>
>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6302804/
>>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>