Kumar Srinivasan | 10 Feb 19:37
Picon
Favicon

Please review: 7131266: JDK 7 pack200 + unpack200 fails on jaxb-xjc.jar

Hello,

Please review fix for : 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131266

The gist of the problem being addressed, the specimen jar contains
two versions of class file implementations with the same package names,
this tends to confuse the pack200 mechanism causing it to fire asserts.

This fixes two issues:
1. Made the equals method more stringent to ensure the CP tag is compared
     correctly [ this can happen for MemberEntry which can have Fields, 
Methods and
     InterfaceMethods,]  and some minor cleanups.

2. A class file not playing nice, ie. package name does not reflect the 
actual
     directory structure they are in,  will not be considered for 
compression, instead
     these will be passed through "as-is".

http://cr.openjdk.java.net/~ksrini/7131266/webrev.0/

Thanks

Kumar

Alex Lam S.L. | 10 Feb 14:52
Picon
Gravatar

Re: FilterOutputStream.close() throws exception from flush()

Hi there,

Thanks for the pointer - I wasn't able to trace back to that email for
some reasons.

The problem is that:

 - flush() is reporting IOException because underlying stream is closed
 - close() is then forwarding that IOException now in JavaSE 8

I guess my question is: what is the best way to check and avoid the
case where OutputStream is already closed?

Regards,
Alex.

On Fri, Feb 10, 2012 at 1:46 PM, Alan Bateman <Alan.Bateman@...> wrote:
> On 10/02/2012 13:09, Alex Lam S.L. wrote:
>>
>> Hi there,
>>
>> I have some code which calls FilterOutputStream.close(), which calls
>> the underlying OutputStream.flush() which throws IOException.
>>
>> With previous versions of JavaSE, close() returns successfully without
>> any problems.
>>
>> Using JDK8-b24, I get an IOException which is propagated from flush().
>>
>> Is there any reason for this change in behaviour?
(Continue reading)

Alex Lam S.L. | 10 Feb 14:09
Picon
Gravatar

FilterOutputStream.close() throws exception from flush()

Hi there,

I have some code which calls FilterOutputStream.close(), which calls
the underlying OutputStream.flush() which throws IOException.

With previous versions of JavaSE, close() returns successfully without
any problems.

Using JDK8-b24, I get an IOException which is propagated from flush().

Is there any reason for this change in behaviour?

Regards,
Alex.

Bill Pugh | 5 Jan 07:02
Picon
Favicon

Re: 100218: BigInteger staticRandom field

OK, I actually starting this bug report when developing a course project (Paul is a student in my class).
I got bit by this using Doug Lea's ParallelArray infrastructure. My code was checking which elements in an
array of 300,000 long values were prime, by checking for divisibility by small primes and then
constructing a BigInteger and calling  isProbablePrime.  But I found that using more than one thread only
gave me slowdowns.

After about a half day of thinking I was using the ParallelArray code incorrectly, I eventually tracked it
down to a bottleneck in the SecureRandom. At first, I figured it was just a problem with the shared
SecureRandom being used in the  private method passesMillerRabin when no Random object is provided.
Since the method is private, I couldn't provide my own Random.

I wound up using reflection to bypass access control and call passesMillerRabin with a Random object
stored in a thread local.

In replicating my benchmarks for this email, I noticed that I was using regular old Random objects rather
than SecureRandom objects (using regular Random objects was good enough for my testing). I found that if I
used a ThreadLocal<SecureRandom>, I was also getting a slow down when doing parallel primality testing.

I spent some time looking at the implementation of SecureRandom and of
sun.security.provider.NativePRNG. The implementation of NativePRNG uses a static singleton to
perform all of the work, so that looked like the concurrency bottleneck. But when I rewrote that class, it
turns out that even removing all of the Java level concurrency bottlenecks, we still can't generate
concurrent secure random numbers, because the NativePRNG reads /dev/urandom for each byte, and that is
inherently sequential and is the bottleneck to the entire process of generating secure random numbers.

So I think the right thing to do is to abandon the original patch, and instead make the following changes:
add the following method to BigInteger public boolean isProbablePrime(int certainty, Random end) ,
which allows primality testing with arbitrary Random objects. In many cases, using a well seeded normal
Random object will work just fine, and this will give users the ability to provide their own Random objects
Document SecureRandom to note that all instances of SecureRandom depend on a common shared source of
(Continue reading)

Louis Wasserman | 18 Jan 20:14
Picon
Gravatar

Float.parseFloat rounding patch

A while back I independently discovered Sun bug
6358355<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6358355> --
basically, under certain conditions, Float.parseFloat just uses a heuristic
to round from Double.parseDouble (it tries to round in the opposite
direction from parseDouble), which predictably enough for a hackish
approach to floating-point rounding, doesn't work correctly in all cases.
 The relevant source is
here<https://bugs.openjdk.java.net/attachment.cgi?id=243&action=diff#a/src/share/classes/sun/misc/FloatingDecimal.java_sec5>;
the comment: "look at the class instance variable roundDir, which should
help us avoid double-rounding error. roundDir was set in hardValueOf if the
estimate was close enough, but not exact. It tells us which direction of
rounding is preferred."

I have a patch and a test at
https://bugs.openjdk.java.net/show_bug.cgi?id=100208, and I was advised to
contact this mailing list to get it reviewed.  What do I need to do?

Louis Wasserman
wasserman.louis@...
http://profiles.google.com/wasserman.louis

Kelly O'Hair | 7 Feb 23:56
Picon
Favicon

Strange messages sent to stderr when using a fastdebug JDK build


I'm seeing all kinds of messages like:

bit length overflow
code 12 bits 6->7

bit length overflow
code 5 bits 6->7

bit length overflow
code 5 bits 6->7

When ever a jdk7u or jdk8 fastdebug built jdk is used.

It appears to be coming from here:

jdk/src/share/native/java/util/zip/zlib-1.2.5/trees.c: Trace((stderr,"\nbit length overflow\n"));

These stderr messages get folded into the java users stderr... I don't think we want that.

-kto

Roger Riggs | 6 Feb 22:16
Picon
Favicon

Review: JDK 8 CR for Support Integer overflow

Thanks for the review and comments:

The comments and suggestions are included in the updated webrev:
    http://cr.openjdk.java.net/~rriggs/6708398.1

  * Corrected error in multipleExact(long,long) with the special case
    Long.MIN_VALUE * -1.
  * Verified that retaining the optimization for small (2^31) arguments
    is worthwhile,
    not doing the divide saves about 1/2 on the execution time.
  * Removed the negateExact methods since they don't pull their weight
    in the API,
    simple tests for MIN_VALUE and MAX_VALUE can be done by the
    developer more efficiently.
  * Simplified the arguments to the ArithmeticExceptions to be simple
    strings since
    debugging this kind of exception requires the source code.
  * Expanded the comments in the implementation include descriptions and
    references to the Hackers Delight where they are used.
  * Updated the tests to include missing test cases

More comments, please

Thanks, Roger

Michael McMahon | 3 Feb 22:23
Picon
Favicon

RFR: 7142617 De-optimize fdlibm compilation [macosx]

Can I get the following change reviewed please?

http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/

fdlibm needs to be compiled with optimization disabled, as on Linux.

Thanks
Michael.

Eamonn McManus | 3 Feb 19:58

Re: Need reviewer: JDK 8 CR for Support Integer overflow

On 3 February 2012 10:22, Vitaly Davidovich <vitalyd@...> wrote:
> x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp against a constant whereas the latter
requires negating x (that's a dependency too), tying up a register to store the negation, and then doing
the cmp.

The value -x is needed anyway since it's the return value. But a more
important reason why my idea is a bad one is that the condition is
true for x == 0! Writing x == -x && x != 0 is definitely not an
improvement.

Éamonn

On 3 February 2012 10:22, Vitaly Davidovich <vitalyd@...> wrote:
>
> x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp against a constant whereas the latter
requires negating x (that's a dependency too), tying up a register to store the negation, and then doing
the cmp.
>
> Sent from my phone
>
> On Feb 3, 2012 12:53 PM, "Eamonn McManus" <eamonn@...> wrote:
>>
>> My initial remarks:
>>
>> In negateExact, the condition x == -x should be faster to evaluate than x
>> == Integer.MIN_VALUE and reflects the intent just as well.
>>
>> In addExact and subtractExact, I would be inclined to implement the int
>> versions using long arithmetic, like this:
>>
(Continue reading)

Roger Riggs | 2 Feb 21:15
Picon
Favicon

Need reviewer: JDK 8 CR for Support Integer overflow

There is a need for arithmetic operations that throw exceptions
when the results overflow the representation of int or long.

The CR is 6708398: Support integer overflow 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6708398>

Please review this webrev 
<http://cr.openjdk.java.net/%7Erriggs/CR6708398/webrev/> to add static 
methods in java.lang.Math
to support addExact(), subtractExact(), negateExact(), multiplyExact(),
and toIntExact() for int and long primitive types.

Thanks, Roger Riggs

Kumar Srinivasan | 1 Feb 22:37
Picon
Favicon

Review request : 7141141 Add 3 new test scenarios for testing Main-Class attribute in jar manifest file

Hi,

Here are some improvements to the launcher tests, contributed by Sonali
Goel of the SQE team, please review:

http://cr.openjdk.java.net/~ksrini/7141141/webrev.0/

The CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141141

Thanks
Kumar


Gmane