On Jun 6, 2015, at 11:02 AM, Peter Levart peter.lev...@gmail.com wrote:
I understand that it would be desirable for a finalizable object to be made
untracked as soon as it is manually cleaned-up. This would most certainly
give a relief to GC as it could reclaim such untracked objects
If that's the case, the documentation needs to be more clear :-) It currently
says:
Clears this reference object. Invoking this method will not cause this object
to be enqueued.
I interpret that as meaning the reference will not be put on the queue as a
part of the clear() call.
The bit of
Staffan,
(1) ByteArrayInputSteram is no longer needed in ZipFile
(2) You've changed the lock region in ZipFile.getInputSteram. Given we are not
doing ByteArrayInpusteram for this method, can we just not touch this
method
and the class ZipFileInputSteram()?
The concern is that we
On 08/06/2015 13:37, Magnus Ihse Bursie wrote:
:
The API functions in Version.java and jvm.h are not finished. The specification
in the JEP talks about a java.util.Version, that I presume will replace the
sun.misc.Version, and that will fully implement an API to access the version
string
On 06/08/2015 09:47 PM, Kim Barrett wrote:
On Jun 6, 2015, at 11:02 AM, Peter Levart peter.lev...@gmail.com wrote:
I understand that it would be desirable for a finalizable object to be made
untracked as soon as it is manually cleaned-up. This would most certainly
give a relief to GC as it
On Jun 8, 2015, at 4:20 PM, Peter Levart peter.lev...@gmail.com wrote:
On 06/08/2015 09:47 PM, Kim Barrett wrote:
On Jun 6, 2015, at 11:02 AM, Peter Levart peter.lev...@gmail.com
wrote:
I understand that it would be desirable for a finalizable object to be made
untracked as soon as
Shouldn't we extend the same notion to other reference types? For Weak/Soft
references, the (rough) equivalent would be a method of the kind:
public void markUnqueueable() // suggestions for better method name most
welcome!
{
this.q = ReferenceQueue.NULL;
}
This is quite useful when
On 06/08/2015 06:53 PM, Rezaei, Mohammad A. wrote:
Shouldn't we extend the same notion to other reference types? For Weak/Soft
references, the (rough) equivalent would be a method of the kind:
public void markUnqueueable() // suggestions for better method name most
welcome!
{
this.q
On Jun 8, 2015, at 1:45 PM, Rezaei, Mohammad A. mohammad.rez...@gs.com wrote:
If that's the case, the documentation needs to be more clear :-) It currently
says:
Clears this reference object. Invoking this method will not cause this
object to be enqueued.
I interpret that as meaning
+1
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
On Jun 8, 2015, at 9:27 PM, joe darcy joe.da...@oracle.com wrote:
Hello,
As an addendum to the
Hello,
As an addendum to the fix-the-warnings JEP, please review this change
which fixes some bad @throws references and the like over in corba:
8086029: Fix doclint reference warnings in org.omg.CORBA
http://cr.openjdk.java.net/~darcy/8086029.0/
Patch below.
Thanks,
-Joe
---
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01
General comment: Not all copyright years were updated.
General comment: It looks like support for the 'patch' value is not
completely
implemented through all the Makefiles. I didn't audit for this, but
it's
Hi Volker,
Your patch reminds me the question I have about loading zip library.
In JDK 9 (and earlier release), zip library is loaded by the VM during
startup (see ClassLoader::load_zip_library). I think loadLibrary(zip)
is no longer needed to be called from System::initializeSystemClass
Hello jaxp and core-libs teams,
FYI, I have some in-progress changes to add Makefile support for tiered
testing:
JDK-8075571: Support tiered testing make targets
http://cr.openjdk.java.net/~darcy/8075571.0/
This involves adding some new TEST.group definitions in the jdk and jaxp
Hi Kim,
Thanks for taking a look at this code.
On 06/09/2015 04:03 AM, Kim Barrett wrote:
On May 31, 2015, at 3:32 PM, Peter Levart peter.lev...@gmail.com wrote:
So, for the curious, here's the improved prototype:
On 9.6.2015 01:31, Daniel D. Daugherty wrote:
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01
langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
old L171: case 1.9:
new L171: case 9:
Hi,
On Sun, 2015-06-07 at 10:46 +0200, Peter Levart wrote:
Hi,
On 06/05/2015 11:11 PM, Jonathan Payne wrote:
My problem was that finalization was not being run at all with the G1
collector. Not at all. That would have been fine with me because none
of the existing objects in the Finalizer
Staffan,
Could you review a CCC request.
http://ccc.us.oracle.com/8059036
-Dmitry
On 2015-06-05 15:24, Staffan Larsen wrote:
Thanks - this version looks good to me.
/Staffan
On 5 jun 2015, at 13:00, Dmitry Samersoff dmitry.samers...@oracle.com
wrote:
Staffan,
Thank you for review!
On 05/06/2015 15:07, Magnus Ihse Bursie wrote:
This review request covers the main part of the work for JEP-223, the
new version string format [1]. Basically, we'll call this release Java
9, instead of Java 1.9.0.
This patch is a folding of all work that has been done so far in the
branch
Hello,
Looks pretty good. Found some typos:
jdk_util.c:
99: specia_update_version
jdk-version.m4:
31: assing
124, 132: --with--version-pre-base has a dash too many? I see this
pattern consistently used though, am I missing something?
/Erik
On 2015-06-05 16:07, Magnus Ihse Bursie wrote:
Thanks!
On 05.06.2015 21:32, Roger Riggs wrote:
Hi Alexander,
Looks good, thanks for the updates.
Roger
On 6/5/2015 1:33 PM, alexander stepanov wrote:
Hello Lance, Roger,
Thank you for the notes, please see the updated webrev:
+1 on Nashorn changes.
-Sundar
On Monday 08 June 2015 06:07 PM, Magnus Ihse Bursie wrote:
8 jun 2015 kl. 11:34 skrev Alan Bateman alan.bate...@oracle.com:
On 05/06/2015 15:07, Magnus Ihse Bursie wrote:
This review request covers the main part of the work for JEP-223, the new version string
Hi,
can I please get a review at least for the part of this fix which is
common for jdk8 and jdk9. It's only a few lines in
src/share/vm/prims/jni.cpp for the hotspot repository and one line
src/java.base/share/classes/java/lang/ClassLoader.java for the jdk
repository.
Thanks,
Volker
On Tue,
Hi Rob,
looks fine to me
thanks for handling this issue
regards
Mark
On 05/06/2015 15:41, Rob McKenna wrote:
Added some cleanup code around the BufferedReaders the leftover test
files:
http://cr.openjdk.java.net/~robm/7130985/webrev.02/
-Rob
On 03/06/15 16:20, Rob McKenna wrote:
Looks good to me too.
Regards,
Sean.
On 08/06/15 13:30, Mark Sheppard wrote:
Hi Rob,
looks fine to me
thanks for handling this issue
regards
Mark
On 05/06/2015 15:41, Rob McKenna wrote:
Added some cleanup code around the BufferedReaders the leftover
test files:
Hello,
Please review distribution of some DTLS feature tests to TLS protocol.
Some DTLS tests may also be used to test the same functionality in TLS
protocol and its versions.
It is test only improvement.
bug: https://bugs.openjdk.java.net/browse/JDK-8085979
webrev:
26 matches
Mail list logo
