Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
This fixes the finalization implementation to invoke the finalize method
via shared secret so that it will call the same method as the bytecode
invocation.
The current implementation uses JNI_GetMethodID to find
On 11/2/2013 3:41 AM, Peter Levart wrote:
On 11/01/2013 10:11 PM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question
On 11/3/13 10:52 PM, Peter Levart wrote:
On 11/04/2013 05:45 AM, Mandy Chung wrote:
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http
Thank you all for the suggestions.
Before the VM initialization is completed, any agent ought to be careful
in what things it can do and what shouldn't do. I think it's reasonable
to ignore System.runFinalization if it's called at early startup phase.
I'm unclear if there is any use case
awaitBooted might as well be
void as it can only ever return true.
Fixed. Revised webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/
Thanks for the review.
Mandy
Thanks,
David
On 5/11/2013 6:04 AM, Mandy Chung wrote:
Thank you all for the suggestions.
Before the VM
On 11/4/2013 6:29 PM, David Holmes wrote:
2. In VM.java. booted need not be volatile now that it is only
accessed within a locked region.
Oops my bad! The accessor wasn't synchronized but now is. Your call
whether to leave as is or revert to previous.
I'm fine with making isBooted() to a
/webrevs/8022208/webrev.02/
I'll let them run longer to see if it can uncover any race. How does
this version look?
Mandy
On 10/31/2013 5:38 PM, David Holmes wrote:
Hi Mandy,
On 1/11/2013 5:11 AM, Mandy Chung wrote:
Updated webrev that has a new
test/lib/testlibrary/ThreadStateController.java
On 11/5/2013 1:11 AM, Paul Sandoz wrote:
On Nov 5, 2013, at 3:21 AM, Mandy Chung mandy.ch...@oracle.com wrote:
2. In VM.java. booted need not be volatile now that it is only accessed within
a locked region. Also awaitBooted might as well be void as it can only ever
return true.
Fixed
On 11/5/2013 2:38 AM, Alan Bateman wrote:
On 05/11/2013 02:21, Mandy Chung wrote:
Fixed. Revised webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/
I looked at the latest webrev.
Having runFinalization and runAllFinalizers be a no-open during
initialization
On 11/4/2013 8:42 PM, David Holmes wrote:
This looks good to me. One nit that caused me some confusion - it took
me a while to realize that in transitionTo eg:
221 public void transitionTo(Thread.State tstate) throws
InterruptedException {
222 switch (tstate) {
223
On 11/5/2013 4:23 PM, David Holmes wrote:
Ship it! :)
Thanks for the review.
And again apologies for sending you down the wrong path on the volatile.
No apology needed. I missed its usage in sun.misc.VM.
Mandy
David
On 6/11/2013 6:25 AM, Mandy Chung wrote:
On 11/5/2013 2:38 AM
. Changeset
pushed.
thanks for the review.
Mandy
I suggest making it static and use static import to shorten the call
site :)
If you do change that, no need for re-review.
David
On 6/11/2013 7:58 AM, Mandy Chung wrote:
On 11/4/2013 8:42 PM, David Holmes wrote:
This looks good to me. One nit
Changeset: 85fd2ae0a845
Author:mchung
Date: 2013-11-05 17:33 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85fd2ae0a845
8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java
6944188: ThreadMXBean/ThreadStateTest.java fails intermittently
Reviewed-by:
This reverts
com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl back
to the previous serial version.
diff --git
a/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java
Looks good.
Mandy
On 11/7/2013 7:02 PM, Stuart Marks wrote:
Hi all,
Please review this quick one-liner to change the serialver tool so
that it emits a serialVersionUID declaration with the 'private'
modifier, which comports with the recommendation in the
java.io.Serializable page.
Bug:
Changeset: b99535e22efe
Author:mchung
Date: 2013-11-07 20:48 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b99535e22efe
8027943: serial version of
com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl changed in
7u45
Reviewed-by: msheppar, alanb, lancea
!
Changeset: 41d7ce111bd8
Author:mchung
Date: 2013-11-08 07:53 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41d7ce111bd8
8027351: (ref) Private finalize method invoked in preference to protected
superclass method
Reviewed-by: alanb, dholmes, mr, plevart, psandoz
!
Changeset: 1c9ba18198d5
Author:mchung
Date: 2013-11-08 09:43 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c9ba18198d5
8028069: (ref) Finalizer.c not deleted in the changeset for JDK-8027351
Reviewed-by: alanb
- src/share/native/java/lang/ref/Finalizer.c
Changeset: 40ca9e4866de
Author:mchung
Date: 2013-11-08 12:13 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40ca9e4866de
8025985: com.sun.management.OSMBeanFactory should not be public
Reviewed-by: alanb, erikj, ihse, jbachorik
! makefiles/lib/ServiceabilityLibraries.gmk
!
thumbs up.
Mandy
On 11/12/13 10:42 AM, Daniel Fuchs wrote:
Hi,
This is a trivial fix to replace a wrong @bug id
in TestRootLoggerLevel.java:
https://bugs.openjdk.java.net/browse/JDK-8026952
I mistakenly put 8023163 (which I was investigating) instead of
8026499 (which is what I was actually
This is a simple code deletion in sun.misc.JavaAWTAccess and its
implementation class:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/
This patch removes the methods from sun.misc.JavaAWTAccess that are no
longer used. The only dependency remaining from core-libs
Adding awt-dev for the review.
Mandy
On 11/12/2013 11:29 AM, Mandy Chung wrote:
This is a simple code deletion in sun.misc.JavaAWTAccess and its
implementation class:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/
This patch removes the methods from
Changeset: 7c55fecfae65
Author:mchung
Date: 2013-11-13 07:49 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c55fecfae65
8028234: Remove unused methods in sun.misc.JavaAWTAccess
Reviewed-by: art, dfuchs, lancea
! src/share/classes/sun/awt/AppContext.java
!
Hi Kumar,
On 11/14/2013 2:57 PM, Kumar Srinivasan wrote:
Hello,
Please review fixes to the launcher tests, which allows for missing
server vm variant.
All SE platforms have server vm, however Embedded SE systems do
not contain server, most of them have client, thus these
tests needed to be
On 11/14/2013 6:54 PM, Kumar Srinivasan wrote:
New full webrev:
http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/index.html
Delta webrev wrt. webrev.0
http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/webrev.delta/index.html
This looks much better. Nit: JAVA_LIB could be
On 11/15/2013 12:37 PM, Ioi Lam wrote:
From sun.misc.Launcher$ExtClassLoader:
private static URL[] getExtURLs(File[] dirs) throws IOException {
VectorURL urls = new VectorURL();
for (int i = 0; i dirs.length; i++) {
String[] files =
On 11/14/2013 1:37 PM, Mark Sheppard wrote:
Hi,
please oblige and review the following fix
http://cr.openjdk.java.net/~msheppar/8028215/webrev/
Looks okay. Seems like it worths some refactoring and change
create_impl to take the classname of the default implementation and move
the
On 11/18/13 8:36 AM, Peter Levart wrote:
On 11/18/2013 04:31 PM, Alan Bateman wrote:
On 18/11/2013 14:59, Jochen Theodorou wrote:
Hi,
java.lang.Class has multiple methods annotated with CallerSensitive
(see
java/lang/management/ThreadMXBean/ThreadStateTest.java has been fixed in [1].
This patch removes it from jdk/test/ProblemList.txt:
$ hg diff ProblemList.txt
diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -122,9 +122,6 @@
#
On 11/19/13 2:23 AM, Daniel Fuchs wrote:
Hi,
Please find below a webrev for:
8028185: XMLFormatter.format emits incorrect year
https://bugs.openjdk.java.net/browse/JDK-8028185
The fix is trivial:
http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/
Looks good. Nit: the test can
Changeset: 48c61808374f
Author:mchung
Date: 2013-11-19 10:19 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48c61808374f
8028565: Remove java/lang/management/ThreadMXBean/ThreadStateTest.java from
ProblemList.txt
Reviewed-by: sla
! test/ProblemList.txt
On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
I am therefore proposing to add an additional check in the test's
setUp() method, in order to verify that the directory is indeed
not writable.
It may be useful to print the owner of the directory in case if it's
running with root permission.
On 11/19/2013 12:12 PM, Daniel Fuchs wrote:
On 11/19/13 9:04 PM, Mandy Chung wrote:
On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
I am therefore proposing to add an additional check in the test's
setUp() method, in order to verify that the directory is indeed
not writable.
It may be useful
with root permission. The
check you added was fine.
thanks
Mandy
-- daniel
On 11/19/13 9:26 PM, Mandy Chung wrote:
On 11/19/2013 12:12 PM, Daniel Fuchs wrote:
On 11/19/13 9:04 PM, Mandy Chung wrote:
On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
I am therefore proposing to add an additional
On 11/19/2013 3:57 PM, Dan Xu wrote:
Hi All,
Please review the simple fix towards Size.java testcase. It failed
once on windows platform in the recent same binary run, which is
mostly due to some interferences and the special delete handling on
windows.
In the fix, I remove the delete
,
http://openjdk.5641.n7.nabble.com/RFR-8022213-Intermittent-test-failures-in-java-net-URLClassLoader-Add-jdk-testlibrary-FileUtils-java-td165561.html.
Thanks!
-Dan
On 11/19/2013 07:08 PM, Mandy Chung wrote:
On 11/19/2013 3:57 PM, Dan Xu wrote:
Hi All,
Please review the simple fix towards
Changeset: 90e27a47ff28
Author:mchung
Date: 2013-11-20 10:00 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90e27a47ff28
8028647: Add instrumentation in GetSafepointSyncTime.java and remove it from
ProblemList.txt
Reviewed-by: sla, chegar
! test/ProblemList.txt
!
This is a simple patch that adds a new jdeps -jdkinternals option to
make it easier for developers to find dependencies on the JDK internal APIs:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/
Mandy
On 11/27/2013 7:52 AM, Dalibor Topic wrote:
On 11/27/13 1:04 PM, Alan Bateman wrote:
On 26/11/2013 23:59, Mandy Chung wrote:
This is a simple patch that adds a new jdeps -jdkinternals option to make it
easier for developers to find dependencies on the JDK internal APIs:
http
On 11/27/13 4:04 AM, Alan Bateman wrote:
On 26/11/2013 23:59, Mandy Chung wrote:
This is a simple patch that adds a new jdeps -jdkinternals option to
make it easier for developers to find dependencies on the JDK
internal APIs:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00
On 11/27/13 4:04 AM, Alan Bateman wrote:
On 26/11/2013 23:59, Mandy Chung wrote:
This is a simple patch that adds a new jdeps -jdkinternals option to
make it easier for developers to find dependencies on the JDK
internal APIs:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00
On 11/29/2013 3:41 AM, Daniel Fuchs wrote:
Hi,
Here is a new revision that includes Peter's findings.
Thanks again for that Peter!
http://cr.openjdk.java.net/~dfuchs/webrev_8029281/webrev.01/
LogManager.java
L156: make props volatile is good.
I think the reason why LoggerWeakRef.node
to
generate a new webrev.
Mandy
Changes are small and outlined below:
On 12/3/13 1:49 AM, Mandy Chung wrote:
On 11/29/2013 3:41 AM, Daniel Fuchs wrote:
Hi,
Here is a new revision that includes Peter's findings.
Thanks again for that Peter!
http://cr.openjdk.java.net/~dfuchs/webrev_8029281
On 12/3/2013 1:44 AM, Peter Levart wrote:
On 12/03/2013 09:51 AM, Peter Levart wrote:
Hi,
While browsing the code of java.util.logging.Handler, I noticed a
theoretical possibility that a security check in a
j.u.l.StreamHandler be circumvented using a data race.
There is a plain boolean
On 12/4/2013 7:51 AM, Alan Bateman wrote:
On 04/12/2013 15:44, Seán Coffey wrote:
Recent jdk8 builds seem to be more ambitious on the GC front. It
turns out that we've no strong reference for the Logger being created
in this testcase and it's collected before use.
Thanks Sean, I've seen this
Changeset: a3b804e3d5f7
Author:mchung
Date: 2013-12-04 09:26 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3b804e3d5f7
7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
hanging intermittently
Reviewed-by: mchung
Contributed-by:
Changeset: 4345e3e82c55
Author:mchung
Date: 2013-12-04 13:35 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4345e3e82c55
8029552: Remove java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
from ProblemList.txt
Reviewed-by: alanb
! test/ProblemList.txt
Changeset: 4a2ed1900428
Author:mchung
Date: 2013-12-04 15:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a2ed1900428
8029216: (jdeps) Provide a specific option to report JDK internal APIs
Reviewed-by: alanb
! src/share/classes/com/sun/tools/jdeps/JdepsTask.java
!
On 12/8/2013 11:19 AM, Peter Levart wrote:
H Mandy,
I created an issue for it nevertheless:
https://bugs.openjdk.java.net/browse/JDK-8029781
You're right, doPrivileged() is a more straight-forward approach than
'sealed' variable. Since this might only be considered for inclusion
in JDK9
Looks good. Happy to see these methods finally removed for a clean jdk
modularization!
Mandy
On 12/10/2013 3:06 AM, Alan Bateman wrote:
(This one is for the jdk9-dev forest once it is created)
The addPropertyChangeListener and removePropertyChangeListener methods
defined by
On 12/10/2013 12:48 AM, Alan Bateman wrote:
On 10/12/2013 04:13, Mandy Chung wrote:
On 12/8/2013 11:19 AM, Peter Levart wrote:
:
You're right, doPrivileged() is a more straight-forward approach
than 'sealed' variable. Since this might only be considered for
inclusion in JDK9 when lambdas
Alan,
The change looks good. A minor one - in the class description of
java.lang.SecurityManager, I suggest to remove the references to
java.awt.AWTPermission line 143 and 214.
Mandy
On 12/10/2013 5:51 AM, Alan Bateman wrote:
In JDK 8 we deprecated the JDK 1.1-era SecurityManager
I have filed https://bugs.openjdk.java.net/browse/JDK-8030010 to clean
up these warning and I can sponsor it.
Mandy
On 12/10/2013 11:17 PM, Staffan Larsen wrote:
I see you were directed here from the build-dev list. Unfortunately these are
core library fixes, not hotspot fixes. I’ve added
On 12/11/2013 1:53 PM, Stuart Marks wrote:
Hi all,
Just one more deprecation task for JDK 8
Please review the following change to rmic to add a warning message
that's emitted when static stubs are generated:
http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/
The change
On 12/11/2013 2:25 PM, Mandy Chung wrote:
On 12/11/2013 1:53 PM, Stuart Marks wrote:
Hi all,
Just one more deprecation task for JDK 8
Please review the following change to rmic to add a warning message
that's emitted when static stubs are generated:
http://cr.openjdk.java.net/~smarks
On 12/11/2013 3:21 PM, Kumar Srinivasan wrote:
Hello,
Please review a fix for Windows launcher where it consumes application
args
-d32 and -d64, the fix is to stop the scan when it hits the
Application sentinel
ie. class-name or jar-name.
http://cr.openjdk.java.net/~ksrini/8029388/webrev.0/
JDK-8021368: Launch of Java Web Start app fails with
ClassCircularityError exception in 7u25
https://bugs.openjdk.java.net/browse/JDK-8021368
This is a fix for 7u60 only. It's a regression in 7u25 due to
JDK-8010117 where it calls Class.getMethod to determine if the
checkMemberAccess method
Hi Peter,
On 12/8/2013 11:19 AM, Peter Levart wrote:
H Mandy,
I created an issue for it nevertheless:
https://bugs.openjdk.java.net/browse/JDK-8029781
You're right, doPrivileged() is a more straight-forward approach than
'sealed' variable. Since this might only be considered for inclusion
Alan.
Thanks for the review.
On 12/13/2013 7:07 AM, Alan Bateman wrote:
I looked at changes and the approach seems okay to me (at least I
can't of other ways to check for the override without also tickling
the issue. I think you are right that a special entry point for this
is excessive
Hi Peter,
Thanks for the review. This code path is critical in this core
reflection implementation and I want to resolve this bug with a low risk
fix in an update release and thus the proposed fix. Thanks for the
experiment with MethodHandles and finding out the pecularity. As a
side
constructors of various
Handlers.
Regards, Peter
On 12/14/2013 12:25 PM, Peter Levart wrote:
Hi Mandy,
On 12/13/2013 12:37 AM, Mandy Chung wrote:
Hi Peter,
On 12/8/2013 11:19 AM, Peter Levart wrote:
H Mandy,
I created an issue for it nevertheless:
https://bugs.openjdk.java.net/browse/JDK-8029781
subclasses by introducing overloaded constructors to
ConfigureActions(s) that follow the overloaded constructors of
various
Handlers.
Regards, Peter
On 12/14/2013 12:25 PM, Peter Levart wrote:
Hi Mandy,
On 12/13/2013 12:37 AM, Mandy Chung wrote:
Hi Peter,
On 12/8/2013 11:19 AM
On 12/17/2013 9:02 AM, Peter Levart wrote:
On 12/17/2013 05:26 PM, Mandy Chung wrote:
This is a good point. The patch for JDK 8 and above uses limited
doPrivileged that only grants LoggingPermission(control) access
even though the system class has all permissions and it should
On 12/18/2013 7:02 AM, Daniel Fuchs wrote:
Hi
Please find below a fix for:
8030192 - [TEST_BUG] java/util/logging/TestLoggerBundleSync.java
failed with NPE
https://bugs.openjdk.java.net/browse/JDK-8030192
http://cr.openjdk.java.net/~dfuchs/webrev_8030192/webrev.00/
The patch
On 12/18/2013 5:55 AM, Peter Levart wrote:
On 12/17/2013 06:43 PM, Mandy Chung wrote:
Can you check what methods are called by the constructors whose
access are denied in the current implementation but granted in the
patch? I have to take another look to make sure but I believe they
only
On 12/19/2013 3:04 AM, Daniel Fuchs wrote:
On 12/18/13 9:35 PM, Mandy Chung wrote:
On 12/17/2013 3:57 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for what I believe is a test bug.
I plan to push this in JDK 9 dev.
https://bugs.openjdk.java.net/browse/JDK-8030187
This seems
On 12/19/13 7:49 AM, Peter Levart wrote:
Hi Mandy, Daniel,
I didn't like the package-protected getters either. So here's another
variant that replaces Handler.configure() method with a
package-protected constructor which is chained from JDK subclasses:
Hi Srikalyan,
Maybe you can get add an uncaught handler to see if you can get
any information. I ran it for 1000 times but not able to duplicate
the failure. Did you run it with jtreg (I didn't)?
Below is the patch to install a thread's uncaught handler that
you can take and try.
diff --git
On 12/20/2013 10:45 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for
8030850: Setting .level=FINEST for the root logger in
logging configuration file doesn't work
https://bugs.openjdk.java.net/browse/JDK-8030850
http://cr.openjdk.java.net/~dfuchs/webrev_8030850/webrev.00/
--- a/src/share/classes/java/lang/reflect/Method.javaFri Dec 20 08:59:52
2013 -0800
+++ b/src/share/classes/java/lang/reflect/Method.javaFri Dec 20 10:26:17
2013 -0800
@@ -251,7 +251,8 @@
}
/**
- * {@inheritDoc}
+ * {@inheritDoc}1
Is this accident? Other than this,
On 12/22/2013 5:23 AM, Peter Levart wrote:
Hi Mandy,
On 12/19/2013 10:38 PM, Mandy Chung wrote:
On 12/19/13 7:49 AM, Peter Levart wrote:
Hi Mandy, Daniel,
I didn't like the package-protected getters either. So here's
another variant that replaces Handler.configure() method with a
package
The patch looks good.
Mandy
On 12/23/13 9:04 AM, Seán Coffey wrote:
Some simple copyright year updates which should have been done during
the year when these corba files were touched. I hope to push to JDK 8
and then import the patch into JDK 9.
The copyright date update looks fine.
Mandy
On 12/23/13 9:56 AM, huizhe wang wrote:
Update copyright date on JAXP files in jdk8 repository edited in 2013.
This patch will be applied to JDK8 and 9 repositories.
https://bugs.openjdk.java.net/browse/JDK-8029236
01:00 PM, srikalyan wrote:
Hi Mandy, yes I ran with JTreg to simulate the failure, i will try
the UEH patch to see if it sheds some light and get back to you.
Thanks for the direction :)
--
Thanks
kalyan
Ph: (408)-585-8040
On 12/19/13, 8:33 PM, Mandy Chung wrote:
Hi Srikalyan,
Maybe you can
On 12/21/2013 8:50 AM, Peter Levart wrote:
Is it possible to get the test output when it fails? It can fail in
two different ways. I can't look at the bug (not authorized)...
You should be able to look at it now. There isn't any other information
besides OOME error.
Exception:
On 1/7/2014 12:30 PM, Joe Darcy wrote:
Hello,
Please review another minor lint fix of a raw type issues in the core
libraries:
Looks good. cc'ing serviceability-dev as java.lang.management is owned
by the serviceability team.
Mandy
On 1/8/2014 11:30 AM, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.01/
The fix looks fine. The WeakReference and System.gc() call was to help
reproduce the test failure. I wonder if it's really needed to be
retained in the test (or better to remove
On 1/8/2014 1:06 AM, Alan Bateman wrote:
On 07/01/2014 22:26, Joe Darcy wrote:
So the type has been deprecated for at least 10 years. Rather than
fixing the warning in the class, I think the best course of action is
to remove the file in JDK 9. A build of OpenJDK without this file
builds
On 1/10/2014 7:37 AM, roger riggs wrote:
Please review:
To enable native code checking consistently for thrown exceptions,
the macros in net_util.h and java/util/jar/pack/coding.cpp are
made consolidated and promoted to jni_util.h
webrev:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6516909/webrev.00/
This patch is to fix:
6516909: (cl spec) ClassLoader.loadClass() clarification to indicate it
shouldn't be used for array classes
4932272: (cl) Remove declaration of the unused private method
ClassLoader.defineClass0
On 1/13/2014 2:44 PM, Kumar Srinivasan wrote:
The full webrev:
http://cr.openjdk.java.net/~ksrini/8031494/webrev.1/
This looks good. Should it also check if there is any pending
exception after the call to CallStaticVoidMethod that has no return
value? It's fine with me if you want to
On 1/13/2014 6:35 PM, Kumar Srinivasan wrote:
Mandy,
On 1/13/2014 2:44 PM, Kumar Srinivasan wrote:
The full webrev:
http://cr.openjdk.java.net/~ksrini/8031494/webrev.1/
This looks good. Should it also check if there is any pending
exception after the call to CallStaticVoidMethod that
On 1/14/2014 2:13 AM, Alan Bateman wrote:
This looks good to me, I assume JDK-6434149 can finally be closed too.
Thanks for the review. Yes JDK-6434149 will be closed.
Mandy
On 1/14/2014 10:17 AM, Kumar Srinivasan wrote:
Good catch on the CallStaticVoidMethod, fixed these as well, here is the
updated webrev:
http://cr.openjdk.java.net/~ksrini/8031494/webrev.2/
delta webrev to the last:
http://cr.openjdk.java.net/~ksrini/8031494/webrev.2/webrev.delta/index.html
Thumbs up.
Mandy
On 1/14/2014 10:39 AM, Lance Andersen wrote:
Hi,
Need a reviewer for this simple change to remove an entry for a test that does
not exist from TEST.groups:
hg diff
diff -r 6744e0c2459f test/TEST.groups
--- a/test/TEST.groups Tue Jan 14 10:08:24 2014 -0800
+++
There is an inconsistency in searching classes vs resources if
bootclasspath contains an empty path. Empty path on bootclasspath is
skipped by the bootstrap class loader when searching classes while it
defaults to current working directory when searching resources as the
application class
On 1/16/2014 7:39 AM, Paul Sandoz wrote:
On Jan 16, 2014, at 2:27 AM, Mandy Chung mandy.ch...@oracle.com wrote:
There is an inconsistency in searching classes vs resources if bootclasspath
contains an empty path. Empty path on bootclasspath is skipped by the
bootstrap class loader when
On 1/17/2014 6:51 AM, Daniel Fuchs wrote:
Hi,
Please find below a webrev for:
8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281
https://bugs.openjdk.java.net/browse/JDK-8031980
http://cr.openjdk.java.net/~dfuchs/webrev_8031980/webrev.00/
The new test looks reasonable.
On 1/20/2014 10:35 AM, Daniel Fuchs wrote:
On 1/20/14 7:17 PM, Mandy Chung wrote:
On 1/17/2014 6:51 AM, Daniel Fuchs wrote:
Hi,
Please find below a webrev for:
8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281
https://bugs.openjdk.java.net/browse/JDK-8031980
http
Hi Tristan,
On 1/21/2014 4:26 PM, Tristan Yan wrote:
Hi Mandy
We have discussed bug https://bugs.openjdk.java.net/browse/JDK-8029891
in JBS. And we don't think this is a good time to fix it. I suggest we
do two things for this bug if it's okay for you.
1. We open a new JDK bug for tracking
On 1/21/2014 5:17 PM, Joe Darcy wrote:
Hi Alan,
Updated webrev at
http://cr.openjdk.java.net/~darcy/8032397.1/
Looks good to me.
@see in sun.misc.Ref removed.
Regression tests updated to not refer to sun.misc.Ref.
I looked at the use of Ref in jhat and it is only used if
This patch looks fine.
For JDK 9, it might be worth considering using the common code via JVM
functions to replace getProcessHandle, JDK_FindJvmEntry,
JDK_InitJvmEntry for native symbol lookup (jni_util.h and jdk_util.h)
Mandy
On 1/24/2014 3:00 AM, Alan Bateman wrote:
I need a reviewer to
On 1/26/2014 11:07 AM, Peter Levart wrote:
On 01/25/2014 05:35 AM, srikalyan chandrashekar wrote:
Hi Peter, if you are a committer would you like to take this further
(OR) perhaps david could sponsor this change.
Hi,
Here's new webrev that takes into account Kaylan's and David's review
On 1/28/14 4:06 AM, Paul Sandoz wrote:
Hi Mike,
Your patch is slightly out of sync with 9:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c8c4f441fc76
This was the changeset I pushed yesterday causing this and removed
sun.lang.ClassLoader.allowArraySyntax. Sorry for the timing.
On 1/29/2014 5:09 AM, Peter Levart wrote:
Since I don't know what should be the correct behaviour of javac, I
can leave the Reference.java changes as proposed since it compiles in
both cases. Or should I revert the change to declaration of local
variable 'q' ?
I slightly prefer to revert
Looks good.
Mandy
On 2/1/2014 10:03 AM, roger riggs wrote:
Hi,
A few small changes to cleanup the name and use of CHECK macros.
The CHECK_NULL_* macros are more generally useful without the JNU_
prefix.
The JNU_CHECK_EXCEPTION* macros apply only when there is an jni
environment.
Webrev:
On 2/3/2014 12:17 PM, roger riggs wrote:
Please re-review.
I missed a warning that the CHECK_NULL macros was being redefined.
Retaining the previous changes to java/util/jar/pack that removed the
redefinition
addresses the issue.
The webrev now only has a few small changes to cleanup the
On 2/3/2014 5:18 AM, Chris Hegarty wrote:
Hi,
An old issue has resurfaced because of a change in AWT. AWT, now, on
Mac OS X, attaches a system graphics thread to the running VM, using
JNI_AttachCurrentThread. This change can result in a NPE, if a
security manager is installed, and the
Thumbs up.
Mandy
On 2/4/2014 10:18 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix [1] for:
8033542: test/java/util/logging/SimpleLogManager might let
Loggers be gc'ed too early. [2]
[1] http://cr.openjdk.java.net/~dfuchs/webrev_8033542/webrev.00
[2]
1 - 100 of 3165 matches
Mail list logo
