Alan,
The heap needs to be increased (1.2GB) for this test, I think the
default provided
by the launcher ergonomics is not sufficient on certain platforms. I've
tested the patch with JPRT.
Thanks
Kumar
diff --git a/test/tools/pack200/Pack200Props.java
b/test/tools/pack200/Pack200Props.java
On 5 Dec 2014, at 17:44, Peter Levart wrote:
> On 12/05/2014 04:09 PM, Chris Hegarty wrote:
>> On 05/12/14 14:40, Peter Levart wrote:
>>> On 12/05/2014 03:04 PM, Chris Hegarty wrote:
On 05/12/14 11:38, Pavel Rappo wrote:
> +1, I couldn’t say better
Right. This bug s
On Thu, Dec 4, 2014 at 5:55 PM, David Holmes wrote:
> In general phrasing like: " also known as a LoadLoad plus LoadStore barrier
> ..." is misleading to me as these are not "aliases"- the loadFence (in this
> case) is being specified to have the same semantics as the
> loadload|storeload. It sho
On Thu, Dec 4, 2014 at 5:36 PM, David Holmes wrote:
> Martin,
>
> On 2/12/2014 6:46 AM, Martin Buchholz wrote:
> Is this finalized then? You can only make one commit per CR.
Right. I'd like to commit and then perhaps do another round of clarifications.
> I still find this entire comment block
Hi David, all,
@David: You're right David.
The loader parameter is never used - I have removed it.
@all: I have received a comment from Alan that it would be better to use
the new jrt:/ FileSystem directly, rather than using private APIs.
One of the consequence is that the te
Looks good,
-Joe
On 12/5/2014 7:22 AM, Kumar Srinivasan wrote:
Hello,
Please review the fix for JDK-8058407, contributed by Neil Toda,
described by JEP 231 [1]
the webrev is at: http://cr.openjdk.java.net/~ksrini/8058407/webrev.00/
Please note: The above webrev is identical to the original
On 5 Dec 2014, at 17:28, Patrick Reinhart wrote:
> Hi Chris,
>
>> Am 05.12.2014 um 17:36 schrieb Chris Hegarty :
>>
>> On 05/12/14 15:59, Alan Bateman wrote:
>>> On 05/12/2014 15:38, Chris Hegarty wrote:
The addition of a copyTo method to java.io.InputStream is binary
compatible [1],
On 12/01/2014 05:58 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057020
There are 2 major LambdaForm caches: LambdaFormEditor-based and
MethodTypeForm. The former is per-LambdaForm and the latter is per
method type
Hang on, I have to increase the Heap size to pack200.exe, I will
repost the changes, when I am done testing with JPRT.
Kumar
On 12/5/2014 9:11 AM, Alan Bateman wrote:
On 05/12/2014 15:49, Kumar Srinivasan wrote:
Hi Alan,
Per your suggestion I have made this othervm.
Thanks
Kumar
Do you want
On 12/05/2014 04:09 PM, Chris Hegarty wrote:
On 05/12/14 14:40, Peter Levart wrote:
On 12/05/2014 03:04 PM, Chris Hegarty wrote:
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug should only try to address the change in behavior that
was inadvertently introduce
Hi Chris,
> Am 05.12.2014 um 17:36 schrieb Chris Hegarty :
>
> On 05/12/14 15:59, Alan Bateman wrote:
>> On 05/12/2014 15:38, Chris Hegarty wrote:
>>> The addition of a copyTo method to java.io.InputStream is binary
>>> compatible [1], but it may, in some cases, be source incompatible. I
>>> beli
On 05/12/2014 15:49, Kumar Srinivasan wrote:
Hi Alan,
Per your suggestion I have made this othervm.
Thanks
Kumar
Do you want to add -Xshare:off too? Just wondering how tight this is on
32-bit Windows.
-Alan.
On 05/12/14 15:59, Alan Bateman wrote:
On 05/12/2014 15:38, Chris Hegarty wrote:
The addition of a copyTo method to java.io.InputStream is binary
compatible [1], but it may, in some cases, be source incompatible. I
believe the benefits of this approach out weigh the potential source
incompatibil
Changes look fine to me Rob.
Thanks.
On 5 Dec 2014, at 05:17, Rob McKenna wrote:
> Just updated the test to workaround a seemingly unrelated platform specific
> issue. (that only manifests on older kernels)
>
> http://cr.openjdk.java.net/~robm/8065238/webrev.02/
>
>-Rob
>
> On 03/12/14
On 05/12/2014 15:38, Chris Hegarty wrote:
The addition of a copyTo method to java.io.InputStream is binary
compatible [1], but it may, in some cases, be source incompatible. I
believe the benefits of this approach out weigh the potential source
incompatibility, but it will be for the spec gods,
Hi Alan,
Per your suggestion I have made this othervm.
Thanks
Kumar
diff --git a/test/tools/pack200/Pack200Props.java
b/test/tools/pack200/Pack200Props.java
--- a/test/tools/pack200/Pack200Props.java
+++ b/test/tools/pack200/Pack200Props.java
@@ -26,7 +26,7 @@
* @bug 6575373 6969063
* @s
On 05/12/14 15:33, Alan Bateman wrote:
On 05/12/2014 14:04, Chris Hegarty wrote:
...
Right, no need for it to be protected. I think what you have seems right
but we probably need a small spec clarification so that it reads "When
not already closed, the close method of FilterOutputStream ..."
The addition of a copyTo method to java.io.InputStream is binary
compatible [1], but it may, in some cases, be source incompatible. I
believe the benefits of this approach out weigh the potential source
incompatibility, but it will be for the spec gods, the CCC, to have
final say.
Here is wha
On 05/12/2014 14:04, Chris Hegarty wrote:
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug should only try to address the change in behavior that
was inadvertently introduced by 7015589[1][2].
I don't see any reason to make 'closed' protected ( part of the pu
Hello,
Please review the fix for JDK-8058407, contributed by Neil Toda,
described by JEP 231 [1]
the webrev is at: http://cr.openjdk.java.net/~ksrini/8058407/webrev.00/
Please note: The above webrev is identical to the original posted by Neal at
http://cr.openjdk.java.net/~ntoda/8058407/webrev
Or, maybe a 3rd, more refined variant:
private boolean closed;
public void close() throws IOException {
Exception exc = null;
try {
flush();
} catch (IOException | RuntimeException e) {
if (!closed) exc = e;
}
try {
On 05/12/14 14:40, Peter Levart wrote:
On 12/05/2014 03:04 PM, Chris Hegarty wrote:
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug should only try to address the change in behavior that
was inadvertently introduced by 7015589[1][2].
What about the following
On 12/05/2014 03:04 PM, Chris Hegarty wrote:
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug should only try to address the change in behavior that
was inadvertently introduced by 7015589[1][2].
What about the following:
private boolean closed;
public voi
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug should only try to address the change in behavior that
was inadvertently introduced by 7015589[1][2].
I don't see any reason to make 'closed' protected ( part of the public
Java SE API ), something like:
diff
Hi Deven,
Similar to lazy initialization of initial list of drivers in
java.sql.DriverManager that was done recently:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029944.html
It would be nice to replace the following pattern:
if (cpath == null) initCannonicalpath();
..
+1, I couldn’t say better
-Pavel
> On 5 Dec 2014, at 01:18, Vitaly Davidovich wrote:
>
> Attempting to make close() atomic just makes the next reader
> confused when the rest of the class isn't and may also penalize single
> threaded callers of close().
Yes - that would be a nice API addition also. Not sure if we'd have to
consider a way of working on system properties set via the command line
option also. I'm tracking this via
https://bugs.openjdk.java.net/browse/JDK-8066709
regards,
Sean.
On 05/12/2014 01:00, Wang Weijun wrote:
A System.s
>
>> Should those methods also be on the FilterInput- and OutputStream?
>
> I'm not sure I'm following you. j.i.FilterInputStream will get the base
> version
> of InputStream.copyTo method for free as a child though it doesn't define it
> itself. Every class down the hierarchy starting from the
28 matches
Mail list logo
