Hi,
I'd be happy with any of the solutions discussed here. In our case, we're only
calling close() multiple times as a result of the way that try-with-resources
works with wrapped streams.
Thanks,
Nathan
Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may throw
IOException if cal
On 9/12/2014 5:25 AM, Martin Buchholz wrote:
Webrev updated to remove the comparison with volatile loads and stores.
Thanks. More inline ...
On Sun, Dec 7, 2014 at 2:40 PM, David Holmes wrote:
On 6/12/2014 7:49 AM, Martin Buchholz wrote:
On Thu, Dec 4, 2014 at 5:55 PM, David Holmes
wrote
Hi Martin,
On 9/12/2014 5:17 AM, Martin Buchholz wrote:
On Mon, Dec 8, 2014 at 12:46 AM, David Holmes wrote:
Martin,
The paper you cite is about ARM and Power architectures - why do you think the
lack of mention of x86/sparc implies those architectures are
multiple-copy-atomic?
Reading so
Reviewed. — John
> On Dec 8, 2014, at 3:47 PM, Vladimir Ivanov
> wrote:
>
> http://cr.openjdk.java.net/~vlivanov/8066746/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8066746
>
> Recent changes (8057656 [1]) broke MHs.explicitCastArguments for
> VarargsCollector case. It introduced a
http://cr.openjdk.java.net/~vlivanov/8066746/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8066746
Recent changes (8057656 [1]) broke MHs.explicitCastArguments for
VarargsCollector case. It introduced an equivalence check between
MHs.explicitCastArguments and MethodHandle.asType() which d
Webrev updated. Field updaters are gone. I intend to commit soon.
On Mon, Dec 8, 2014 at 2:00 PM, Martin Buchholz wrote:
> Alright, I'm convinced and will revert to using ordinary volatile
> writes instead of CAS.
>
> Y'all have a deeper understanding of the reflection machinery.
>
> Martin
>
>
Alright, I'm convinced and will revert to using ordinary volatile
writes instead of CAS.
Y'all have a deeper understanding of the reflection machinery.
Martin
On Mon, Dec 8, 2014 at 1:52 PM, Peter Levart wrote:
>
> On 12/08/2014 10:24 PM, Peter Levart wrote:
>
> "Interned" Types can not be guar
On 12/08/2014 10:24 PM, Peter Levart wrote:
"Interned" Types can not be guaranteed, since they are rooted on
members of j.l.Class (Method, Field, Constructor), which can be GC-ed
because of either:
- class redefinition
- memory pressure (see j.l.Class.reflectionData field, which points to
So
On 12/08/2014 10:24 PM, Peter Levart wrote:
On 12/08/2014 09:31 PM, Martin Buchholz wrote:
(sorry for missing this message earlier)
On Tue, Dec 2, 2014 at 1:49 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/
Hi Martin,
I see lots o
On 12/08/2014 09:09 PM, Vladimir Ivanov wrote:
Peter,
Just one more thought...
In lines:
358 } else if (stale < 0 && k.get() == null) {
359 stale = i; // remember 1st stale entry
index
360 }
...an index to 1st stale en
On 12/08/2014 09:31 PM, Martin Buchholz wrote:
(sorry for missing this message earlier)
On Tue, Dec 2, 2014 at 1:49 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/
Hi Martin,
I see lots of "changes" in javadocs that appear to have sa
(sorry for missing this message earlier)
On Tue, Dec 2, 2014 at 1:49 AM, Paul Sandoz wrote:
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/
>>
>
> I am not convinced about the use of CAS. If we can get away with just
> volatile fields I think the code is simp
Hi Chris,
> Am 08.12.2014 um 15:17 schrieb Chris Hegarty :
>
> Again, just for completeness...
>
> Some feedback from Paul Sandoz, to be explicit about the "openness" of the
> streams on return. "Does not close either stream."
>
> /**
> * Reads all bytes from this input stream and writes t
Peter,
Just one more thought...
In lines:
358 } else if (stale < 0 && k.get() == null) {
359 stale = i; // remember 1st stale entry index
360 }
...an index to 1st stale entry is remembered while scanning the array so
that
Peter,
Thanks for looking into that and for you initial prototype!
So WeakReferences did not hold LambdaForms long enough even with strong
back-reference from LambdaForm to the lambda form 'this' was derived
from? So final derived LambdaForms (leaves) are not kept referenced from
the code? Or d
Webrev updated to remove the comparison with volatile loads and stores.
On Sun, Dec 7, 2014 at 2:40 PM, David Holmes wrote:
> On 6/12/2014 7:49 AM, Martin Buchholz wrote:
>>
>> On Thu, Dec 4, 2014 at 5:55 PM, David Holmes
>> wrote:
>>
>>> In general phrasing like: " also known as a LoadLoad plus
On Mon, Dec 8, 2014 at 12:46 AM, David Holmes wrote:
> Martin,
>
> The paper you cite is about ARM and Power architectures - why do you think
> the lack of mention of x86/sparc implies those architectures are
> multiple-copy-atomic?
Reading some more in the same paper, I see:
"""Returning to t
+1
On Dec 8, 2014, at 1:54 PM, Stuart Marks wrote:
> I broke RMIConnector_NPETest again. This time it was passing a timeout value
> that caused some time calculations to overflow, causing the RMI test library
> to time out prematurely.
>
> Please review this fix, which is to limit timeout valu
I broke RMIConnector_NPETest again. This time it was passing a timeout value
that caused some time calculations to overflow, causing the RMI test library to
time out prematurely.
Please review this fix, which is to limit timeout values to something reasonable
and to change the test to use the
On 12/8/2014 12:24 AM, Alan Bateman wrote:
On 08/12/2014 06:24, joe darcy wrote:
Hello,
Please review the simple patch below to fix
JDK-8066643: (zipfs) Suppress deprecation warnings in jdk.zipfs
module
This looks for now although it would be nicer to re-implement these
two methods to
On 12/8/2014 9:11 AM, Alan Bateman wrote:
On 08/12/2014 17:06, Kumar Srinivasan wrote:
Hi Alan,
adding javacpl to BLACKLIST_VERSION array.
Looks good and sorry we missed in the JEP 220 changes, it wasn't
obvious that there was an issue because the test passes.
No apologies needd, in fact I s
On 08/12/2014 17:06, Kumar Srinivasan wrote:
Hi Alan,
adding javacpl to BLACKLIST_VERSION array.
Looks good and sorry we missed in the JEP 220 changes, it wasn't obvious
that there was an issue because the test passes.
-Alan
Hi Alan,
adding javacpl to BLACKLIST_VERSION array.
Thanks
Kumar
diff --git a/test/tools/launcher/VersionCheck.java
b/test/tools/launcher/VersionCheck.java
--- a/test/tools/launcher/VersionCheck.java
+++ b/test/tools/launcher/VersionCheck.java
@@ -69,6 +69,7 @@
"java-rmi",
"
looks fine.
On 12/7/14 10:24 PM, joe darcy wrote:
Hello,
Please review the simple patch below to fix
JDK-8066643: (zipfs) Suppress deprecation warnings in jdk.zipfs
module
Thanks,
-Joe
diff -r 913808eaf19a
src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
--- a/src/jdk.zipfs/s
On Dec 6, 2014, at 1:30 PM, Peter Levart wrote:
> Now what scares me (might be that I don't have an intimacy with LambdaForm
> class like you do). There is a situation where you publish LambdaForm
> instances via data race.
>
> One form of LambdaForm.transformCache is an array of Transform obje
Again, just for completeness...
Some feedback from Paul Sandoz, to be explicit about the "openness" of
the streams on return. "Does not close either stream."
/**
* Reads all bytes from this input stream and writes the bytes to
the given
* output stream in the order that they are re
On 08/12/2014 11:48, Chris Hegarty wrote:
For completeness, here is the finalized spec that we intend to submit
for approval. Just some minor rewording and grammaticality amendments
over the previous.
/**
* Reads all bytes from this input stream and writes the bytes to
the given
For completeness, here is the finalized spec that we intend to submit
for approval. Just some minor rewording and grammaticality amendments
over the previous.
/**
* Reads all bytes from this input stream and writes the bytes to
the given
* output stream in the order that they are
+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 Dec 8, 2014, at 1:24 AM, joe darcy wrote:
>
> Hello,
>
> Please review the simple patch below to fix
>
>
Just one more thought...
In lines:
358 } else if (stale < 0 && k.get() == null) {
359 stale = i; // remember 1st stale entry index
360 }
...an index to 1st stale entry is remembered while scanning the array so
that at the end,
Martin,
The paper you cite is about ARM and Power architectures - why do you think the
lack of mention of x86/sparc implies those architectures are
multiple-copy-atomic?
David
> -Original Message-
> From: Martin Buchholz [mailto:marti...@google.com]
> Sent: Monday, 8 December 2014 6:42
On Sun, Dec 7, 2014 at 2:58 PM, David Holmes wrote:
>> I believe the comment _does_ reflect hotspot's current implementation
>> (entirely from exploring the sources).
>> I believe it's correct to say "all of the platforms are
>> multiple-copy-atomic except PPC".
... current hotspot sources don't
On 08/12/2014 06:24, joe darcy wrote:
Hello,
Please review the simple patch below to fix
JDK-8066643: (zipfs) Suppress deprecation warnings in jdk.zipfs
module
This looks for now although it would be nicer to re-implement these two
methods to do this conversion without using Date.
-Ala
On 08/12/2014 00:56, Kumar Srinivasan wrote:
Alan,
I have adjust both the tests Pack200Props as well as Pack200Test which
uses
rt.jar to have increased heaps and -Xshare:off.
http://cr.openjdk.java.net/~ksrini/8066745/webrev.00/
This looks good to me.
-Alan
34 matches
Mail list logo
