RFR(S): JDK-8073175, 8073174: Fix native warnings in libjli and libfdlibm
Hi Everyone, It's my $0.02 to the warning cleanup work. Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01 http://cr.openjdk.java.net/~dsamersoff/JDK-8073174/webrev.01 Notes: 1. There are two common ways to cast pointer to int: intptr_t (perfectly safe, more-or-less portable) and size_t (perfectly portable, more-or-less safe) So I use size_t in shared code, intptr_t in UNIX specific code. 2. I didn't fix format not a string literal warnings. It requires to set per-compiler pragmas. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
Re: RFR(S): JDK-8073175, 8073174: Fix native warnings in libjli and libfdlibm
On Feb 15, 6:52pm, dmitry.samers...@oracle.com (Dmitry Samersoff) wrote: -- Subject: RFR(S): JDK-8073175, 8073174: Fix native warnings in libjli and l | Hi Everyone, | | It's my $0.02 to the warning cleanup work. Please review: | | http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01 | http://cr.openjdk.java.net/~dsamersoff/JDK-8073174/webrev.01 | | Notes: | | 1. | There are two common ways to cast pointer to int: intptr_t (perfectly | safe, more-or-less portable) and size_t (perfectly portable, | more-or-less safe) | | So I use size_t in shared code, intptr_t in UNIX specific code. | Why are you using a signed and an unsigned type? You should probably be using uintptr_t for consistency. christos
Re: RFR 8073124: Tune test and document TimSort runs length stack size increase
On 14/02/2015 12:03 AM, Lev Priima wrote: Please review and push: http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8073124 I hadn't realized 8072909 had been pushed without final reviewer comments being addressed. :( These changes seem okay. I hope they get promoted at the same time as the original changeset so we don't get test failures. Thanks, David Lev On 02/13/2015 05:20 AM, David Holmes wrote: Hi Lev, On 13/02/2015 2:56 AM, Lev Priima wrote: Christos, Test may fail on shorter arrays(page 8 of paper). For instance, on worst case, generated by test, it starts to fail on length 67108864. After increasing stack size of runs to merge, Arrays.sort(T[]) works also on maximum possible array for HotSpot JVM. I'd also like to see this documented somewhere in the code. Presently there is a reference to listsort.txt but then you have to go and find it on the web. :( At a minimum could we please add: 175 * computation below must be changed if MIN_MERGE is decreased. See 176 * the MIN_MERGE declaration above for more information. + * The maximum value of 49 allows for an array up to length + * Integer.MAX_VALUE-4. Roger, David, I've updated the test ( http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html ) to make it more suitable for regular execution: 27 * @run main/othervm TimSortStackSize2 67108864 This will still fail on small memory devices: :~ java TimSortStackSize2 67108864 Exception in thread main java.lang.OutOfMemoryError: Java heap space as the default heap ergonomics may not be large enough. I had to add a minimum heap of -Xmx385M to get it to run. Thanks, David 28 * not for regular execution on all platforms: 29 * run main/othervm -Xmx8g TimSortStackSize2 1073741824 30 * run main/othervm -Xmx32g TimSortStackSize2 2147483644 Could you please push this: http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/ ? Lev On 02/12/2015 12:54 PM, chris...@zoulas.com wrote: On Feb 12, 9:57pm,david.hol...@oracle.com (David Holmes) wrote: -- Subject: Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on | Ok - thanks Lev! | | David For posterity can someone document this, and also the value for which Integer.MAX_VALUE-4 fails? christos
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
Brian pointed out to me that this change missed to add the annotation to bridge
methods. Here is an updated version that takes those into account. I also
needed to update the test to verify that bridge methods were correctly
annotated - it got a little bit more complex since I had to force bridges being
used.
new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.01/
http://cr.openjdk.java.net/~sla/8025636/webrev.01/
Thanks,
/Staffan
On 3 feb 2015, at 10:15, Staffan Larsen staffan.lar...@oracle.com wrote:
Hi,
Please review this patch for hiding the lambda proxy frame in stack traces:
bug: https://bugs.openjdk.java.net/browse/JDK-8025636
https://bugs.openjdk.java.net/browse/JDK-8025636
webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/
http://cr.openjdk.java.net/~sla/8025636/webrev.00/
This is a straightforward addition of the LambdaForm$Hidden annotation to the
generated methods. What is surprising is that this works even if
LambdaForm$Hidden is a package-private class in java.lang.invoke and thus not
accessible from most of the generated classes. There is some discussion of
and answers to this in the bug, but essentially this works because the
annotation class is never resolved and the code in Hotspot that looks for the
annotation amounts to nothing more than string comparisons.
Hidden stack frames can be shown by running with
“-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames”.
For an example of what this patch does, consider this code:
Runnable r = () - { throw new RuntimeException(); };
r.run();
Previously, this would output:
java.lang.RuntimeException
at pkg.Foo.lambda$main$0(Foo.java:5)
at pkg.Foo$$Lambda$1/2001112025.run(Unknown:100)
at pkg.Foo.main(Foo.java:15)
With the patch it looks like this:
java.lang.RuntimeException
at pkg.Foo.lambda$main$0(Foo.java:5)
at pkg.Foo.main(Foo.java:15)
Thanks,
/Staffan
