Hi,
On 06/29/2015 11:45 AM, Andrew Haley wrote:
Hi,
On 29/06/15 10:41, Zoltán Majó wrote:
On 06/27/2015 10:05 AM, Andrew Haley wrote:
On 25/06/15 12:49, Zoltán Majó wrote:
Problem: There is need to indicate Java methods that are potentially
intrinsified by JVM.
It's a great idea but is it
Bitten again by the very same issue :(
The following code doesn't compile:
static K, T FunctionK, T factory(Consumer? super BiConsumer? super
K, ? super T consumer, Function? super K, ? extends T ifAbsent) {
HashMapK, T map = new HashMap();
consumer.accept(map::put);
return key -
On 29.6.2015 12:09, Alan Bateman wrote:
On 29/06/2015 10:10, Jan Lahoda wrote:
Thanks for the comment - done that. Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/full/
Delta against the previous iteration:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/delta/
On Jun 29, 2015, at 12:41 PM, Zoltán Majó zoltan.m...@oracle.com wrote:
Hi,
On 06/29/2015 11:45 AM, Andrew Haley wrote:
Hi,
On 29/06/15 10:41, Zoltán Majó wrote:
On 06/27/2015 10:05 AM, Andrew Haley wrote:
On 25/06/15 12:49, Zoltán Majó wrote:
Problem: There is need to indicate
On 06/29/2015 01:38 PM, Doug Simon wrote:
I seems just plain wrong for an intrinsic to not implement the same
semantics as the intrinsified method. I would expect an intrinsic to
perform all necessary runtime checks and only have the compiler omit
them if it can prove they are unnecessary. If
Hi,
On 29/06/15 10:41, Zoltán Majó wrote:
On 06/27/2015 10:05 AM, Andrew Haley wrote:
On 25/06/15 12:49, Zoltán Majó wrote:
Problem: There is need to indicate Java methods that are potentially
intrinsified by JVM.
It's a great idea but is it a good name? HotSpot is not the only Java
VM.
Thanks Paul.
I have another cleaner patch coming - I'll include those
changes as well.
-- daniel
On 29/06/15 11:13, Paul Sandoz wrote:
On Jun 29, 2015, at 10:35 AM, Daniel Fuchs daniel.fu...@oracle.com wrote:
On 29/06/15 10:06, Paul Sandoz wrote:
That's odd i would of expected it to work.
On 29/06/15 11:13, Paul Sandoz wrote:
NetBeans didn't suggest replacing with diamonds either - which it
usually does - but then maybe it was busy scanning classpath;-)
This is a relatively new 9-based language feature, so i don't expect the IDEs
have caught up yet (IntelliJ 15 EAP has not for
Hi James,
thank you for your feedback!
I've implemented the changes you suggested, here is the updated webrev:
- top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.07/
- jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.07/
- hotspot:
On 06/28/2015 09:21 PM, Alan Bateman wrote:
On 26/06/2015 16:43, Zoltán Majó wrote:
I updated the indentation as well.
Here is the updated webrev:
- top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/
- jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/
- hotspot:
Hi Andrew,
On 06/27/2015 10:05 AM, Andrew Haley wrote:
On 25/06/15 12:49, Zoltán Majó wrote:
Problem: There is need to indicate Java methods that are potentially
intrinsified by JVM.
It's a great idea but is it a good name? HotSpot is not the only Java
VM. Do we expect people from to come
On 29.6.2015 12:09, Alan Bateman wrote:
On 29/06/2015 10:10, Jan Lahoda wrote:
Thanks for the comment - done that. Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/full/
Delta against the previous iteration:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/delta/
On 27.06.2015 21:54, Martin Buchholz wrote:
On Sat, Jun 27, 2015 at 5:46 AM, Ivan Gerasimov
ivan.gerasi...@oracle.com mailto:ivan.gerasi...@oracle.com wrote:
Hi Martin!
Thank you for this cleanup!
Removal of wrong comments looks fine.
But your webrev contains commented
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8042983
Patch: see diff below
Summary: Restrict test execution to systems having at least 1GB of physical
memory.
Thanks,
Brian
--- a/test/java/math/BigInteger/ExtremeShiftingTests.java
+++
On Jun 29, 2015, at 3:01 PM, Andrew Haley a...@redhat.com wrote:
On 06/29/2015 01:38 PM, Doug Simon wrote:
I seems just plain wrong for an intrinsic to not implement the same
semantics as the intrinsified method. I would expect an intrinsic to
perform all necessary runtime checks and
Hi Brian,
This looks fine. I recommend monitoring the impact of this test and
adjusting up the max memory limit if running test continues to cause issues.
Thanks,
-Joe
On 6/29/2015 10:30 AM, Brian Burkhalter wrote:
Please review at your convenience.
Issue:
On 29/06/2015 10:10, Jan Lahoda wrote:
Thanks for the comment - done that. Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/full/
Delta against the previous iteration:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/delta/
How does this look? Feedback is
Maybe it's better to live with PrivilegedActionClassLoader and
PrivilegedActionString instead? I'm using NetBeans 8.0.2, it looks
like it doesn't support source level beyond JDK 1.8. It's a bit
bothersome to have red flags. Plus, we won't be able to build with JDK
8. What would you think?
Hi Daniel,
Another great cleanup! The change looks good to me. Only minor
suggestion: same as 8129956, would you want to add the types back
instead of using diamond operator? It looks good, but the red flags in
the NetBeans could be a bit troublesome. Plus, honestly, I still
regularly
On Jun 29, 2015, at 10:48 AM, Doug Simon doug.si...@oracle.com wrote:
As I understand it, part of this change is to split intrinsification into one
method that does the checks that then calls a second method which the VM may
intrinsify on the assumption all checks have been performed by the
Hi,
Discovered a late bug where signed JARs would not be verified using the
faster path as the verification is done on the returned stream.
The JarFile.getInputStream will return different stream types depending
on if the entry should be verified or not.
Also added a size check of the entry
On Jun 29, 2015, at 10:35 AM, Daniel Fuchs daniel.fu...@oracle.com wrote:
On 29/06/15 10:06, Paul Sandoz wrote:
That's odd i would of expected it to work. Here's Joe's patch to changes in
the JDK:
http://cr.openjdk.java.net/~darcy/8078467.0/jdk.patch
(Search for new PrivilegedAction
On 26.6.2015 16:00, Alan Bateman wrote:
On 26/06/2015 14:38, Jan Lahoda wrote:
Uploaded a new iteration of the patch, reflecting the comments so far,
here:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.02/full/
A delta patch from previous iteration:
On Jun 27, 2015, at 2:13 PM, Daniel Fuchs daniel.fu...@oracle.com wrote:
On 6/27/15 12:57 PM, Peter Levart wrote:
Hi Daniel,
Just a question. Would diamonds on anonymous instance creation expressions
work in these cases?
I tried it - it didn't work.
You would have to use a local
Hi Martin!
I agree that since the commented code only contains an assert statement,
it's unlikely to be confused with a real method.
It is helpful to have the invariants documented, so yes, it looks good.
Sincerely yours,
Ivan
On 30.06.2015 0:56, Martin Buchholz wrote:
On Mon, Jun 29,
On 25/06/2015 8:29 PM, Ivan Gerasimov wrote:
Hi David!
The test fails when reading content of existing jsse.jar, which belongs
to compact3 profile.
When the test loads classes from this jar and tries to access their
fields, it hits the types that are not included in compact[12], thus
26 matches
Mail list logo
