JDK 9 RFR of JDK-8037174: Fix serial lint warnings in sun.applet
Hello,
Please review the patch below to address
JDK-8037174: Fix serial lint warnings in sun.applet
http://cr.openjdk.java.net/~darcy/8037174.0/
Thanks,
-Joe
--- old/src/share/classes/sun/applet/AppletEvent.java2014-03-11
23:15:49.0 -0700
+++ new/src/share/classes/sun/applet/AppletEvent.java2014-03-11
23:15:49.0 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -33,7 +33,7 @@
*
* @author Sunita Mani
*/
-
+@SuppressWarnings("serial") // JDK-implementation class
public class AppletEvent extends EventObject {
private Object arg;
--- old/src/share/classes/sun/applet/AppletIOException.java 2014-03-11
23:15:49.0 -0700
+++ new/src/share/classes/sun/applet/AppletIOException.java 2014-03-11
23:15:49.0 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -32,6 +32,7 @@
*
* @author Koji Uno
*/
+@SuppressWarnings("serial") // JDK implementation class
public
class AppletIOException extends IOException {
private String key = null;
--- old/src/share/classes/sun/applet/AppletIllegalArgumentException.java
2014-03-11 23:15:50.0 -0700
+++ new/src/share/classes/sun/applet/AppletIllegalArgumentException.java
2014-03-11 23:15:50.0 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -30,6 +30,7 @@
*
* @author Arthur van Hoff
*/
+@SuppressWarnings("serial") // JDK implementation class
public
class AppletIllegalArgumentException extends IllegalArgumentException {
private String key = null;
--- old/src/share/classes/sun/applet/AppletPanel.java2014-03-11
23:15:50.0 -0700
+++ new/src/share/classes/sun/applet/AppletPanel.java2014-03-11
23:15:50.0 -0700
@@ -62,6 +62,7 @@
*
* @author Arthur van Hoff
*/
+@SuppressWarnings("serial") // JDK implementation class
public
abstract class AppletPanel extends Panel implements AppletStub, Runnable {
--- old/src/share/classes/sun/applet/AppletProps.java2014-03-11
23:15:51.0 -0700
+++ new/src/share/classes/sun/applet/AppletProps.java2014-03-11
23:15:51.0 -0700
@@ -37,6 +37,7 @@
import sun.security.action.*;
+@SuppressWarnings("serial") // JDK implementation class
class AppletProps extends Frame {
TextField proxyHost;
@@ -194,7 +195,7 @@
/* 4066432 */
/* Dialog class to display property-related errors to user */
-
+@SuppressWarnings("serial") // JDK implementation class
class AppletPropsErrorDialog extends Dialog {
public AppletPropsErrorDialog(Frame parent, String title, String
message,
String buttonText) {
--- old/src/share/classes/sun/applet/AppletSecurityException.java
2014-03-11 23:15:51.0 -0700
+++ new/src/share/classes/sun/applet/AppletSecurityException.java
2014-03-11 23:15:51.0 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1995, 1998, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -30,6 +30,7 @@
*
* @author Arthur van Hoff
*/
+@SuppressWarnings("serial") // JDK-implementation class
public
class AppletSecurityException extends SecurityException {
private String key = null;
--- old/src/share/classes/sun/applet/AppletViewer.java2014-03-11
23:15:52.0 -0700
+++ new/src/share/classes/sun/applet/AppletViewer.java2014-03-11
23:15:52.0 -0700
@@ -46,6 +46,7 @@
/**
* A frame to show the applet tag in.
*/
+@SuppressWarnings("serial") // JDK-implementation class
class TextFrame extends Frame {
/**
@@ -115,6 +116,7 @@
* (The document named appletviewertags.html in the JDK's
docs/tooldocs directory,
* once the JDK docs have been installed.)
*/
+@SuppressWarnings("serial") // JDK implementation class
public class AppletViewer extends Frame implements AppletContext,
Printable {
--- old/src/share/classes/sun/applet/Main.java2014-03-11
23:15:52.0 -0700
+++ new/src/share/classes/sun/ap
Re: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails
On 11/03/2014 10:24 PM, Ivan Gerasimov wrote: Hello everybody! The test java/lang/ProcessBuilder/CloseRace.java was reported to intermittently fail. The test timed out, which should mean that at least one of the child threads was never interrupted. I couldn't reproduce the failure, but I suspect it might happen due to call to interrupt() before the child thread became alive (I'm not really sure if it's possible to be non-alive after call to start()). It isn't. There's no reason the interrupt() would not be sent. More likely problem is that the thread gets stuck in those busy-loops for some reason; or the process.waitFor does not respond to the interrupt (not sure how that is handled). Need a stack-dump of a hung process. David - The fix is to explicitly synchronize children with the parent. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ Sincerely yours, Ivan
Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty
On Feb 21 2014, at 14:56 , Martin Buchholz wrote:
> You should do -> code conversion separately, and do it pervasively
> across the entire JDK.
From your lips to God's ears I keep suggesting this along with a restyle to
official style every time we create new repos. Seems unlikely unfortunately as
it makes backports harder.
> This is not right.
> + * {@code
> (o==null ? get(i)==null : o.equals(get(i)))}
Corrected.
> You accidentally deleted a stray space here?
>
> -this.elementData = EMPTY_ELEMENTDATA;
> + this.elementData = EMPTY_ELEMENTDATA;
Corrected.
> public ArrayList(int initialCapacity) {
> -super();
> if (initialCapacity < 0)
> throw new IllegalArgumentException("Illegal Capacity: "+
> initialCapacity);
> -this.elementData = new Object[initialCapacity];
> +this.elementData = (initialCapacity > 0)
> +? new Object[initialCapacity]
> +: EMPTY_ELEMENTDATA;
> }
>
> When optimizing for special cases, we should try very hard minimize overhead
> in the common case. In the above, we now have two branches in the common
> case. Instead,
>
> if (initialCapacity > 0) this.elementData = new Object[initialCapacity];
> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA;
> else barf
Corrected.
Thanks as always for the feedback.
Mike
>
>
>
> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote:
> Hello all;
>
> This changeset consists of two small performance improvements for ArrayList.
> Both are related to the lazy initialization introduced in JDK-8011200.
>
> The first change is in the ArrayList(int capacity) constructor and forces
> lazy initialization if the requested capacity is zero. It's been observed
> that in cases where zero capacity is requested that it is very likely that
> the list never receives any elements. For these cases we permanently avoid
> the allocation of an element array.
>
> The second change, noticed by Gustav Åkesson, involves the
> ArrayList(Collection c) constructor. If c is an empty collection then there
> is no reason to inflate the backing array for the ArrayList.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/
>
> I also took the opportunity to the -> {@code } conversion for the
> javadoc.
>
> Enjoy!
>
> Mike
>
Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty
I've actually always used scp. :-)
Since I accepted all of your changes as suggested and had no other changes I
was just going to go ahead and push once testing was done.
I've now prepared a revised webrev and can still accept feedback.
http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/
(Note: The webrev also contains
https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing the
two issues together.)
Mike
On Mar 11 2014, at 16:42 , Martin Buchholz wrote:
> I don't see the updated webrev. Maybe you also fell victim to "rsync to cr
> no longer working"?
>
>
> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote:
>
> On Feb 21 2014, at 14:56 , Martin Buchholz wrote:
>
>> You should do -> code conversion separately, and do it pervasively
>> across the entire JDK.
>
> From your lips to God's ears I keep suggesting this along with a restyle
> to official style every time we create new repos. Seems unlikely
> unfortunately as it makes backports harder.
>
>> This is not right.
>> + * {@code
>> (o==null ? get(i)==null : o.equals(get(i)))}
>
> Corrected.
>
>> You accidentally deleted a stray space here?
>>
>> -this.elementData = EMPTY_ELEMENTDATA;
>> + this.elementData = EMPTY_ELEMENTDATA;
>
> Corrected.
>
>> public ArrayList(int initialCapacity) {
>> -super();
>> if (initialCapacity < 0)
>> throw new IllegalArgumentException("Illegal Capacity: "+
>> initialCapacity);
>> -this.elementData = new Object[initialCapacity];
>> +this.elementData = (initialCapacity > 0)
>> +? new Object[initialCapacity]
>> +: EMPTY_ELEMENTDATA;
>> }
>>
>> When optimizing for special cases, we should try very hard minimize overhead
>> in the common case. In the above, we now have two branches in the common
>> case. Instead,
>>
>> if (initialCapacity > 0) this.elementData = new Object[initialCapacity];
>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA;
>> else barf
>
> Corrected.
>
> Thanks as always for the feedback.
>
> Mike
>
>>
>>
>>
>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote:
>> Hello all;
>>
>> This changeset consists of two small performance improvements for ArrayList.
>> Both are related to the lazy initialization introduced in JDK-8011200.
>>
>> The first change is in the ArrayList(int capacity) constructor and forces
>> lazy initialization if the requested capacity is zero. It's been observed
>> that in cases where zero capacity is requested that it is very likely that
>> the list never receives any elements. For these cases we permanently avoid
>> the allocation of an element array.
>>
>> The second change, noticed by Gustav Åkesson, involves the
>> ArrayList(Collection c) constructor. If c is an empty collection then there
>> is no reason to inflate the backing array for the ArrayList.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/
>>
>> I also took the opportunity to the -> {@code } conversion for the
>> javadoc.
>>
>> Enjoy!
>>
>> Mike
>>
>
>
Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty
On Mar 11 2014, at 17:42 , Martin Buchholz wrote:
> I'm hoping y'all have evidence that empty ArrayLists are common in the wild.
Yes, certainly. From the original proposal:
> [This change] based upon analysis that shows that in large applications as
> much as 10% of maps and lists are initialized but never receive any entries.
> A smaller number spend a large proportion of their lifetime empty. We've
> found similar results across other workloads as well.
> It is curious that empty lists grow immediately to 10, while ArrayList with
> capacity 1 grows to 2, then 3... Some people might think that a bug.
Yes, that's unfortunate. I've made another version that uses a second sentinel
for the default sized but empty case.
Now I want to reduce the ensureCapacity reallocations! It seems like insane
churn to replace the arrays that frequently.
> There are more changes that need to be reverted.
> Else looks good.
> - * More formally, returns the lowest index i such that
> - *
> (o==null ? get(i)==null : o.equals(get(i))),
> + * More formally, returns the lowest index {@code i} such that
> + * {@code
> (o==null ? get(i)==null : o.equals(get(i)))},
Corrected. Thank you.
http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/
Mike
>
>
> On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou wrote:
> I've actually always used scp. :-)
>
> Since I accepted all of your changes as suggested and had no other changes I
> was just going to go ahead and push once testing was done.
>
> I've now prepared a revised webrev and can still accept feedback.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/
>
> (Note: The webrev also contains
> https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing
> the two issues together.)
>
> Mike
>
> On Mar 11 2014, at 16:42 , Martin Buchholz wrote:
>
>> I don't see the updated webrev. Maybe you also fell victim to "rsync to cr
>> no longer working"?
>>
>>
>> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote:
>>
>> On Feb 21 2014, at 14:56 , Martin Buchholz wrote:
>>
>>> You should do -> code conversion separately, and do it pervasively
>>> across the entire JDK.
>>
>> From your lips to God's ears I keep suggesting this along with a restyle
>> to official style every time we create new repos. Seems unlikely
>> unfortunately as it makes backports harder.
>>
>>> This is not right.
>>> + * {@code
>>> (o==null ? get(i)==null : o.equals(get(i)))}
>>
>> Corrected.
>>
>>> You accidentally deleted a stray space here?
>>>
>>> -this.elementData = EMPTY_ELEMENTDATA;
>>> + this.elementData = EMPTY_ELEMENTDATA;
>>
>> Corrected.
>>
>>> public ArrayList(int initialCapacity) {
>>> -super();
>>> if (initialCapacity < 0)
>>> throw new IllegalArgumentException("Illegal Capacity: "+
>>> initialCapacity);
>>> -this.elementData = new Object[initialCapacity];
>>> +this.elementData = (initialCapacity > 0)
>>> +? new Object[initialCapacity]
>>> +: EMPTY_ELEMENTDATA;
>>> }
>>>
>>> When optimizing for special cases, we should try very hard minimize
>>> overhead in the common case. In the above, we now have two branches in the
>>> common case. Instead,
>>>
>>> if (initialCapacity > 0) this.elementData = new Object[initialCapacity];
>>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA;
>>> else barf
>>
>> Corrected.
>>
>> Thanks as always for the feedback.
>>
>> Mike
>>
>>>
>>>
>>>
>>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This changeset consists of two small performance improvements for
>>> ArrayList. Both are related to the lazy initialization introduced in
>>> JDK-8011200.
>>>
>>> The first change is in the ArrayList(int capacity) constructor and forces
>>> lazy initialization if the requested capacity is zero. It's been observed
>>> that in cases where zero capacity is requested that it is very likely that
>>> the list never receives any elements. For these cases we permanently avoid
>>> the allocation of an element array.
>>>
>>> The second change, noticed by Gustav Åkesson, involves the
>>> ArrayList(Collection c) constructor. If c is an empty collection then there
>>> is no reason to inflate the backing array for the ArrayList.
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/
>>>
>>> I also took the opportunity to the -> {@code } conversion for the
>>> javadoc.
>>>
>>> Enjoy!
>>>
>>> Mike
>>>
>>
>>
>
>
Re: RFR: 8037097: (s) Improve diagnosability of test failures for java/util/Arrays/Correct.java
On 3/11/14 3:31 PM, Mike Duigou wrote: Hello all; The test java/util/Arrays/Correct.java (yeah, great name...) has failed intermittently in nightly testing. Unfortunately the currently committed version does not provide much information on the failure condition. This changeset is a renovation of the test to hopefully provide additional clues to the root cause should the test fail again. It also adds somewhat more thorough testing as well as generifies and TestNGifies the source. http://cr.openjdk.java.net/~mduigou/JDK-8037097/0/webrev/ Looks good to me. Mandy
RFR: 8037097: (s) Improve diagnosability of test failures for java/util/Arrays/Correct.java
Hello all; The test java/util/Arrays/Correct.java (yeah, great name...) has failed intermittently in nightly testing. Unfortunately the currently committed version does not provide much information on the failure condition. This changeset is a renovation of the test to hopefully provide additional clues to the root cause should the test fail again. It also adds somewhat more thorough testing as well as generifies and TestNGifies the source. http://cr.openjdk.java.net/~mduigou/JDK-8037097/0/webrev/ Mike
Re: RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails
Thank you Martin!
On 11.03.2014 19:04, Martin Buchholz wrote:
Thanks for working on my brittle racy tests.
Adding a latch as you did is a good improvement, although there's a
good chance the real problem lies elsewhere.
My standard name for such latches is "threadsStarted", which I think
is a bit better than "startedSignal". Please rename.
No problem, renamed.
My simple calls to Thread.join are too optimistic.
More likely to be helpful is code like (pseudocode follows):
thread.join(10, SECONDS);
if (thread.isAlive()) {
dumpAllStacks();
fail();
}
Yes, it was a good idea to do that!
After implementing your suggestion, I could finally reproduce the failure.
The OpenLoop child thread was spinning in the do-while loop, waiting for
'count of fds in use' to become 3.
The simple solution is to add a check weather the current thread is
interrupted to this and other loops.
Would you please take a look at the updated webrev?
http://cr.openjdk.java.net/~igerasim/8034262/1/webrev/
Sincerely yours,
Ivan
That's more work to implement - optional.
On Tue, Mar 11, 2014 at 5:24 AM, Ivan Gerasimov
mailto:ivan.gerasi...@oracle.com>> wrote:
Hello everybody!
The test java/lang/ProcessBuilder/CloseRace.java was reported to
intermittently fail.
The test timed out, which should mean that at least one of the
child threads was never interrupted.
I couldn't reproduce the failure, but I suspect it might happen
due to call to interrupt() before the child thread became alive
(I'm not really sure if it's possible to be non-alive after call
to start()).
The fix is to explicitly synchronize children with the parent.
Would you please help review the fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262
WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/
Re: RFR[9](XXS): 8037013: [TESTBUG] Fix test/java/lang/ClassLoader/Assert.sh on AIX
Hi Mandy, thanks for the review. I'll look into the possibility of removing Assert.sh altogether and post a new webrev soon. Regards, Volker On Tue, Mar 11, 2014 at 2:59 AM, Mandy Chung wrote: > > On 3/10/2014 11:55 AM, Mandy Chung wrote: >> >> Hi Volker, >> >> On 3/10/14 11:16 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following trivial change which adds AIX to >>> the list of known OSs in test/java/lang/ClassLoader/Assert.sh: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8037013 >>> http://cr.openjdk.java.net/~simonis/webrevs/8037013/ >>> >> >> The link to your webrev is not accessible and could possibly due to the >> server issue. I guess your fix is to add AIX in the Assert.sh test. Can >> you paste the diff in mail? I can review it. >> > > I am able to access the webrev now - looks good. > > >> I raised in the code review of 7152892 [1] that I believe this test >> doesn't need to be a shell test. I don't know if Rob has started looking >> into it (he missed my review comment when he pushed the fix). I wonder if >> you would like to take the opportunity to investigate if Assert.sh can be >> removed? >> > > It'd be even better if we could get rid of Assert.sh. > > thanks > Mandy > >> Mandy >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024995.html > >
Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
Sergey, On Mar 11, 2014, at 1:18 AM, Sergey Kuksenko wrote: > Could you share your benchmarks? Of course. Please see: benchmark source: http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java benchmark results: http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html Let us know should you find anything amiss. Thanks, Brian
Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
On Mar 11 2014, at 01:05 , Sergey Kuksenko wrote: > Brian, Mike. > > Could you explain what is the problem with the old caching? Concern over heap pollution with extra string copies was the motivation to ensure that only a single cached instance was ever returned. > String is immutable, BigDecimal is immutable. So we have data race at that > place, but it is safe data race. Agreed that it is safe. > What is the problem if we create several identical strings? We can still create several identical strings. We will now only return the first assigned to stringCache. Other string instances will not escape. > You are making stringCache volatile -> performance penalty on ARM & PPC. It is understood that the volatile is not "free". For this purpose it was believed that the performance cost was a fair trade off to avoid the heap pollution. Regardless of the decision in this case the method used would seem to be the best caching pattern available. We do need to establish when it is appropriate to use this solution and what the tradeoffs are that would make other solutions more appropriate. > Setting cache via CAS -> performance penalty everywhere. This happens only once per BigDecimal (or not at all if the string format is never generated). > If you insist to use AtomicFieldUpdater - the better way is to use lazySet, > not CAS. That would seem to be inappropriate for this usage as lazySet would effectively remove that volatile. Brian did some benchmarking of various alternatives which he can probably provide if we think it is relevant to the performance issue you're concerned with. Mike
Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)
So all you're achieving by annotating prepend() method is that any
exception stack trace, in case it is thrown inside the prepend() method,
will hide where it was thrown from. In case all LambdaForm frames
leading to the prepend() method were also hidden, the exception would
appear to be thrown from the invocation of the MH...
Yes. Also, Thread.dumpStack() won't list it.
Do you see any problem here?
Best regards,
Vladimir Ivanov
Regards, Peter
Best regards,
Vladimir Ivanov
Regards, Peter
There's not much value in it in this particular case, but I decided to
reduce possible noise.
Best regards,
Vladimir Ivanov
On 3/11/14 3:35 PM, Peter Levart wrote:
Hi,
Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden
annotation?
I suspect it has to do with hiding the call frames in stack traces
that
are part of LambdaForm invocation chain. In this case, method:
private static Object[] prepend(Object elem, Object[] array)
in MethodHandleImpl need not be annotated with this annotation, since
it's call frame is not on stack when one of the target methods is
executed. It's just a function used to calculate the argument of the
call. In fact, if prepend() ever throws exception (NPE in case
array is
null?), It would be preferable that it's call frame is visible in the
stack trace.
Am I right or am I just talking nonsense?
Regards, Peter
On 03/11/2014 12:12 AM, Vladimir Ivanov wrote:
John, Chris, thanks!
Best regards,
Vladimir Ivanov
On 3/11/14 3:08 AM, Christian Thalinger wrote:
Even better.
On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov
wrote:
Chris, thanks for the review.
John suggested an elegant way to fix the problem - use
asFixedArity.
Updated fix:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/
Best regards,
Vladimir Ivanov
On 3/8/14 4:51 AM, Christian Thalinger wrote:
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target,
Object... args) throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8036117
84 lines changed: 74 ins; 3 del; 7 mod
I have to revert a cleanup I did for 8027827.
MethodHandle.invokeWithArguments (and generic invocation) has
unpleasant
peculiarity in behavior when used with VarargsCollector. So,
unfortunately, invokeWithArguments is not an option there.
Looking at the API (excerpts from javadoc [1] [2]), the following
condition doesn't hold in that case:
"trailing parameter type of the caller is a reference type
identical
to or assignable to the trailing parameter type of the adapter".
Example:
target.invokeWithArguments((Object[])args)
=>
target.invoke((Object)o1,(Object)o2,(Object)o3)
=/>
target.invokeExact((Object)o1, (Object)o2, (Object[])o3)
because Object !<: Object[].
The fix is to skip unnecessary conversion when invoking a method
handle
and just do a pairwise type conversion.
Testing: failing test case, nashorn w/ experimental features
(octane)
Thanks!
Best regards,
Vladimir Ivanov
[1] MethodHandle.invokeWithArguments
"Performs a variable arity invocation, ..., as if via an inexact
invoke
from a call site which mentions only the type Object, and whose
arity is
the length of the argument array."
[2] MethodHandle.asVarargsCollector
"When called with plain, inexact invoke, if the caller type is
the
same
as the adapter, the adapter invokes the target as with
invokeExact.
(This is the normal behavior for invoke when types match.)
Otherwise, if the caller and adapter arity are the same, and the
trailing parameter type of the caller is a reference type
identical to
or assignable to the trailing parameter type of the adapter, the
arguments and return values are converted pairwise, as if by
asType on a
fixed arity method handle.
Otherwise, the arities differ, or the adapter's trailing
parameter
type
is not assignable from the corresponding caller type. In this
case, the
adapter replaces all trailing arguments from the original
trailing
argument position onward, by a new array of type arrayType, whose
elements comprise (in order) the replaced arguments."
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_
Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)
On 03/11/2014 03:05 PM, Vladimir Ivanov wrote:
You raised totally valid question.
I marked MethodHandleImpl.prepend with @Hidden annotation because it
is internal implementation detail of JSR292.
You are right that normally a callee can't see it on stack. *But it's
possible to observe it when stack trace is queried from a separate
thread. *
Is this good or bad? It enables tools to see it (for example sampling
profilers, etc...).
For the purposes of sampling profilers (and other monitoring tools)
@Hidden should be completely ignored. These tools should use
appropriate API to get the data.
I looked into the code and @Hidden has even less effect than I thought
initially. It affects very limited set of cases - only users of
JVM_FillInStackTrace (when filling exception's stack trace,
Thread.dumpStack()). Calls to Thread.getStackTrace() from a separate
thread omit stack trace filtering.
So all you're achieving by annotating prepend() method is that any
exception stack trace, in case it is thrown inside the prepend() method,
will hide where it was thrown from. In case all LambdaForm frames
leading to the prepend() method were also hidden, the exception would
appear to be thrown from the invocation of the MH...
Regards, Peter
Best regards,
Vladimir Ivanov
Regards, Peter
There's not much value in it in this particular case, but I decided to
reduce possible noise.
Best regards,
Vladimir Ivanov
On 3/11/14 3:35 PM, Peter Levart wrote:
Hi,
Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden
annotation?
I suspect it has to do with hiding the call frames in stack traces
that
are part of LambdaForm invocation chain. In this case, method:
private static Object[] prepend(Object elem, Object[] array)
in MethodHandleImpl need not be annotated with this annotation, since
it's call frame is not on stack when one of the target methods is
executed. It's just a function used to calculate the argument of the
call. In fact, if prepend() ever throws exception (NPE in case
array is
null?), It would be preferable that it's call frame is visible in the
stack trace.
Am I right or am I just talking nonsense?
Regards, Peter
On 03/11/2014 12:12 AM, Vladimir Ivanov wrote:
John, Chris, thanks!
Best regards,
Vladimir Ivanov
On 3/11/14 3:08 AM, Christian Thalinger wrote:
Even better.
On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov
wrote:
Chris, thanks for the review.
John suggested an elegant way to fix the problem - use
asFixedArity.
Updated fix:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/
Best regards,
Vladimir Ivanov
On 3/8/14 4:51 AM, Christian Thalinger wrote:
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target,
Object... args) throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8036117
84 lines changed: 74 ins; 3 del; 7 mod
I have to revert a cleanup I did for 8027827.
MethodHandle.invokeWithArguments (and generic invocation) has
unpleasant
peculiarity in behavior when used with VarargsCollector. So,
unfortunately, invokeWithArguments is not an option there.
Looking at the API (excerpts from javadoc [1] [2]), the following
condition doesn't hold in that case:
"trailing parameter type of the caller is a reference type
identical
to or assignable to the trailing parameter type of the adapter".
Example:
target.invokeWithArguments((Object[])args)
=>
target.invoke((Object)o1,(Object)o2,(Object)o3)
=/>
target.invokeExact((Object)o1, (Object)o2, (Object[])o3)
because Object !<: Object[].
The fix is to skip unnecessary conversion when invoking a method
handle
and just do a pairwise type conversion.
Testing: failing test case, nashorn w/ experimental features
(octane)
Thanks!
Best regards,
Vladimir Ivanov
[1] MethodHandle.invokeWithArguments
"Performs a variable arity invocation, ..., as if via an inexact
invoke
from a call site which mentions only the type Object, and whose
arity is
the length of the argument array."
[2] MethodHandle.asVarargsCollector
"When called with plain, inexact invoke, if the caller type is
the
same
as the adapter, the adapter invokes the target as with
invokeExact.
(This is the normal behavior for invoke when types match.)
Otherwise, if the caller and adapter arity are the same, and the
trailing parameter type of the caller is a reference type
identical to
or assignable to the trailing parameter type of the adapter, the
arguments and return values are converted pairwise, as if by
asType on a
fixed arity method handle.
Otherwise, the arities differ, or the adapter's trailing
parameter
type
is not assignable from the corresponding caller type. In this
case, the
adapter replaces all trailing arguments from the original
trailing
argument position onward, by a new array of type arrayType, whose
elements co
Re: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems
What about providing a shell script with JDK 9 with functions to encode names? Users can then just "source" the file into their scripts and helper functions available to them. Hopefully this would alleviate dealing with special characters. On Tue, Mar 11, 2014 at 8:22 AM, Alan Bateman wrote: > On 11/03/2014 12:09, Peter Levart wrote: > >> : >> >> What is the purpose of changing the scheme? Is it just to be more >> power-user and developer friendly? To enable users to inspect the >> preferences with filesystem tools? What about a little command-line and/or >> gui "jprefs" tool in the style of regedit or gconftool or similar? Would >> that be enough to satisfy the goal? Any of the options A...D seem a >> compatibility nightmare for majority of programs that use preferences. Most >> users don't ever inspect directories starting with dot '.', so this feature >> is more or less targeted at developers, right? A tool that is standard part >> of JRE distribution could do the job of browsing (and perhaps changing of) >> the preferences without compatibility concerns... >> > This is mostly about complaints from those with scripts that are forced to > deal with special characters in the file name. I don't think the > preferences API is used very much so it might not be worth doing anything. > If it does change and it might need a tool to migrate existing preferences, > all depends on the approach. > > -Alan > -- Cheers, Paul
Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)
You raised totally valid question.
I marked MethodHandleImpl.prepend with @Hidden annotation because it
is internal implementation detail of JSR292.
You are right that normally a callee can't see it on stack. *But it's
possible to observe it when stack trace is queried from a separate
thread. *
Is this good or bad? It enables tools to see it (for example sampling
profilers, etc...).
For the purposes of sampling profilers (and other monitoring tools)
@Hidden should be completely ignored. These tools should use
appropriate API to get the data.
I looked into the code and @Hidden has even less effect than I thought
initially. It affects very limited set of cases - only users of
JVM_FillInStackTrace (when filling exception's stack trace,
Thread.dumpStack()). Calls to Thread.getStackTrace() from a separate
thread omit stack trace filtering.
Best regards,
Vladimir Ivanov
Regards, Peter
There's not much value in it in this particular case, but I decided to
reduce possible noise.
Best regards,
Vladimir Ivanov
On 3/11/14 3:35 PM, Peter Levart wrote:
Hi,
Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden
annotation?
I suspect it has to do with hiding the call frames in stack traces that
are part of LambdaForm invocation chain. In this case, method:
private static Object[] prepend(Object elem, Object[] array)
in MethodHandleImpl need not be annotated with this annotation, since
it's call frame is not on stack when one of the target methods is
executed. It's just a function used to calculate the argument of the
call. In fact, if prepend() ever throws exception (NPE in case array is
null?), It would be preferable that it's call frame is visible in the
stack trace.
Am I right or am I just talking nonsense?
Regards, Peter
On 03/11/2014 12:12 AM, Vladimir Ivanov wrote:
John, Chris, thanks!
Best regards,
Vladimir Ivanov
On 3/11/14 3:08 AM, Christian Thalinger wrote:
Even better.
On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov
wrote:
Chris, thanks for the review.
John suggested an elegant way to fix the problem - use asFixedArity.
Updated fix:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/
Best regards,
Vladimir Ivanov
On 3/8/14 4:51 AM, Christian Thalinger wrote:
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target,
Object... args) throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8036117
84 lines changed: 74 ins; 3 del; 7 mod
I have to revert a cleanup I did for 8027827.
MethodHandle.invokeWithArguments (and generic invocation) has
unpleasant
peculiarity in behavior when used with VarargsCollector. So,
unfortunately, invokeWithArguments is not an option there.
Looking at the API (excerpts from javadoc [1] [2]), the following
condition doesn't hold in that case:
"trailing parameter type of the caller is a reference type
identical
to or assignable to the trailing parameter type of the adapter".
Example:
target.invokeWithArguments((Object[])args)
=>
target.invoke((Object)o1,(Object)o2,(Object)o3)
=/>
target.invokeExact((Object)o1, (Object)o2, (Object[])o3)
because Object !<: Object[].
The fix is to skip unnecessary conversion when invoking a method
handle
and just do a pairwise type conversion.
Testing: failing test case, nashorn w/ experimental features
(octane)
Thanks!
Best regards,
Vladimir Ivanov
[1] MethodHandle.invokeWithArguments
"Performs a variable arity invocation, ..., as if via an inexact
invoke
from a call site which mentions only the type Object, and whose
arity is
the length of the argument array."
[2] MethodHandle.asVarargsCollector
"When called with plain, inexact invoke, if the caller type is the
same
as the adapter, the adapter invokes the target as with invokeExact.
(This is the normal behavior for invoke when types match.)
Otherwise, if the caller and adapter arity are the same, and the
trailing parameter type of the caller is a reference type
identical to
or assignable to the trailing parameter type of the adapter, the
arguments and return values are converted pairwise, as if by
asType on a
fixed arity method handle.
Otherwise, the arities differ, or the adapter's trailing parameter
type
is not assignable from the corresponding caller type. In this
case, the
adapter replaces all trailing arguments from the original trailing
argument position onward, by a new array of type arrayType, whose
elements comprise (in order) the replaced arguments."
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing l
Re: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems
On 11/03/2014 12:09, Peter Levart wrote: : What is the purpose of changing the scheme? Is it just to be more power-user and developer friendly? To enable users to inspect the preferences with filesystem tools? What about a little command-line and/or gui "jprefs" tool in the style of regedit or gconftool or similar? Would that be enough to satisfy the goal? Any of the options A...D seem a compatibility nightmare for majority of programs that use preferences. Most users don't ever inspect directories starting with dot '.', so this feature is more or less targeted at developers, right? A tool that is standard part of JRE distribution could do the job of browsing (and perhaps changing of) the preferences without compatibility concerns... This is mostly about complaints from those with scripts that are forced to deal with special characters in the file name. I don't think the preferences API is used very much so it might not be worth doing anything. If it does change and it might need a tool to migrate existing preferences, all depends on the approach. -Alan
RFR [8034262] Test java/lang/ProcessBuilder/CloseRace.java fails
Hello everybody! The test java/lang/ProcessBuilder/CloseRace.java was reported to intermittently fail. The test timed out, which should mean that at least one of the child threads was never interrupted. I couldn't reproduce the failure, but I suspect it might happen due to call to interrupt() before the child thread became alive (I'm not really sure if it's possible to be non-alive after call to start()). The fix is to explicitly synchronize children with the parent. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034262 WEBREV: http://cr.openjdk.java.net/~igerasim/8034262/0/webrev/ Sincerely yours, Ivan
Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)
On 03/11/2014 12:59 PM, Vladimir Ivanov wrote:
Peter,
You raised totally valid question.
I marked MethodHandleImpl.prepend with @Hidden annotation because it
is internal implementation detail of JSR292.
You are right that normally a callee can't see it on stack. *But it's
possible to observe it when stack trace is queried from a separate
thread. *
Is this good or bad? It enables tools to see it (for example sampling
profilers, etc...).
Regards, Peter
There's not much value in it in this particular case, but I decided to
reduce possible noise.
Best regards,
Vladimir Ivanov
On 3/11/14 3:35 PM, Peter Levart wrote:
Hi,
Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden
annotation?
I suspect it has to do with hiding the call frames in stack traces that
are part of LambdaForm invocation chain. In this case, method:
private static Object[] prepend(Object elem, Object[] array)
in MethodHandleImpl need not be annotated with this annotation, since
it's call frame is not on stack when one of the target methods is
executed. It's just a function used to calculate the argument of the
call. In fact, if prepend() ever throws exception (NPE in case array is
null?), It would be preferable that it's call frame is visible in the
stack trace.
Am I right or am I just talking nonsense?
Regards, Peter
On 03/11/2014 12:12 AM, Vladimir Ivanov wrote:
John, Chris, thanks!
Best regards,
Vladimir Ivanov
On 3/11/14 3:08 AM, Christian Thalinger wrote:
Even better.
On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov
wrote:
Chris, thanks for the review.
John suggested an elegant way to fix the problem - use asFixedArity.
Updated fix:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/
Best regards,
Vladimir Ivanov
On 3/8/14 4:51 AM, Christian Thalinger wrote:
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target,
Object... args) throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8036117
84 lines changed: 74 ins; 3 del; 7 mod
I have to revert a cleanup I did for 8027827.
MethodHandle.invokeWithArguments (and generic invocation) has
unpleasant
peculiarity in behavior when used with VarargsCollector. So,
unfortunately, invokeWithArguments is not an option there.
Looking at the API (excerpts from javadoc [1] [2]), the following
condition doesn't hold in that case:
"trailing parameter type of the caller is a reference type
identical
to or assignable to the trailing parameter type of the adapter".
Example:
target.invokeWithArguments((Object[])args)
=>
target.invoke((Object)o1,(Object)o2,(Object)o3)
=/>
target.invokeExact((Object)o1, (Object)o2, (Object[])o3)
because Object !<: Object[].
The fix is to skip unnecessary conversion when invoking a method
handle
and just do a pairwise type conversion.
Testing: failing test case, nashorn w/ experimental features
(octane)
Thanks!
Best regards,
Vladimir Ivanov
[1] MethodHandle.invokeWithArguments
"Performs a variable arity invocation, ..., as if via an inexact
invoke
from a call site which mentions only the type Object, and whose
arity is
the length of the argument array."
[2] MethodHandle.asVarargsCollector
"When called with plain, inexact invoke, if the caller type is the
same
as the adapter, the adapter invokes the target as with invokeExact.
(This is the normal behavior for invoke when types match.)
Otherwise, if the caller and adapter arity are the same, and the
trailing parameter type of the caller is a reference type
identical to
or assignable to the trailing parameter type of the adapter, the
arguments and return values are converted pairwise, as if by
asType on a
fixed arity method handle.
Otherwise, the arities differ, or the adapter's trailing parameter
type
is not assignable from the corresponding caller type. In this
case, the
adapter replaces all trailing arguments from the original trailing
argument position onward, by a new array of type arrayType, whose
elements comprise (in order) the replaced arguments."
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems
On 03/10/2014 10:12 PM, Brian Burkhalter wrote: This issue (https://bugs.openjdk.java.net/browse/JDK-8029770) concerns improving preference handling (java.util.prefs.Preferences) on systems other than Mac OS X and Windows, essentially Unix systems other than OS X. It would be good to obtain some comments on the behavior of the prospective changes including whether they are even necessary. For the moment, comments on the behavior are of more interest than those on any particular implementation. For background, on the Unix systems in question, the file system is used to store preferences in a tree with nodes mapping to directories. As node names can contain characters which may cause confusion when used verbatim in directory names, in those cases where such characters are detected, the directory name is derived from the node name by encoding the latter using a non-standard variant of the Base 64 Alphabet (Table 1 in [1]) which is immune to alphabetic character case folding. This can result in some strange and human unreadable directory names in the file system preferences tree. The objective here would be to change this scheme to something more user friendly. There are likely numerous approaches to solving this problem, but I think that first it needs to be determined whether interoperability with earlier Java versions is a requirement and, if so, what the nature of this requirement is. There are probably others, but there are at least the following alternatives (not all of which might be sensible): A) No interoperability: Java 9 and subsequent versions would not share preferences with earlier versions. B) Initialization only: Java 9 preferences would be initialized from the state of pre-9 preferences at the instant of first use. C) Unidirectional: Java 9 would detect changes made by earlier versions. D) Bidirectional: Java 9 and pre-9 preferences would be kept in sync. For options C and D note that only Java 9+ instances could effect this behavior. If for example Java 9 was not run for some time on a particular machine, the pre-9 preferences could significantly diverge from the 9 preferences. These would presumably be brought into sync when a Java 9+ instance next invoked the Preferences APIs. Whichever option were chosen, the changes made could include the definition of a system property which could be set to disable the new preferences handling variant, i.e., to force pre-9 file system preferences behavior. Any comments would be appreciated. Thanks, Brian [1] http://tools.ietf.org/rfc/rfc4648.txt Hi Brian, What is the purpose of changing the scheme? Is it just to be more power-user and developer friendly? To enable users to inspect the preferences with filesystem tools? What about a little command-line and/or gui "jprefs" tool in the style of regedit or gconftool or similar? Would that be enough to satisfy the goal? Any of the options A...D seem a compatibility nightmare for majority of programs that use preferences. Most users don't ever inspect directories starting with dot '.', so this feature is more or less targeted at developers, right? A tool that is standard part of JRE distribution could do the job of browsing (and perhaps changing of) the preferences without compatibility concerns... Regards, Peter
Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)
Peter,
You raised totally valid question.
I marked MethodHandleImpl.prepend with @Hidden annotation because it is
internal implementation detail of JSR292.
You are right that normally a callee can't see it on stack. But it's
possible to observe it when stack trace is queried from a separate thread.
There's not much value in it in this particular case, but I decided to
reduce possible noise.
Best regards,
Vladimir Ivanov
On 3/11/14 3:35 PM, Peter Levart wrote:
Hi,
Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden
annotation?
I suspect it has to do with hiding the call frames in stack traces that
are part of LambdaForm invocation chain. In this case, method:
private static Object[] prepend(Object elem, Object[] array)
in MethodHandleImpl need not be annotated with this annotation, since
it's call frame is not on stack when one of the target methods is
executed. It's just a function used to calculate the argument of the
call. In fact, if prepend() ever throws exception (NPE in case array is
null?), It would be preferable that it's call frame is visible in the
stack trace.
Am I right or am I just talking nonsense?
Regards, Peter
On 03/11/2014 12:12 AM, Vladimir Ivanov wrote:
John, Chris, thanks!
Best regards,
Vladimir Ivanov
On 3/11/14 3:08 AM, Christian Thalinger wrote:
Even better.
On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov
wrote:
Chris, thanks for the review.
John suggested an elegant way to fix the problem - use asFixedArity.
Updated fix:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/
Best regards,
Vladimir Ivanov
On 3/8/14 4:51 AM, Christian Thalinger wrote:
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target,
Object... args) throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8036117
84 lines changed: 74 ins; 3 del; 7 mod
I have to revert a cleanup I did for 8027827.
MethodHandle.invokeWithArguments (and generic invocation) has
unpleasant
peculiarity in behavior when used with VarargsCollector. So,
unfortunately, invokeWithArguments is not an option there.
Looking at the API (excerpts from javadoc [1] [2]), the following
condition doesn't hold in that case:
"trailing parameter type of the caller is a reference type
identical
to or assignable to the trailing parameter type of the adapter".
Example:
target.invokeWithArguments((Object[])args)
=>
target.invoke((Object)o1,(Object)o2,(Object)o3)
=/>
target.invokeExact((Object)o1, (Object)o2, (Object[])o3)
because Object !<: Object[].
The fix is to skip unnecessary conversion when invoking a method
handle
and just do a pairwise type conversion.
Testing: failing test case, nashorn w/ experimental features (octane)
Thanks!
Best regards,
Vladimir Ivanov
[1] MethodHandle.invokeWithArguments
"Performs a variable arity invocation, ..., as if via an inexact
invoke
from a call site which mentions only the type Object, and whose
arity is
the length of the argument array."
[2] MethodHandle.asVarargsCollector
"When called with plain, inexact invoke, if the caller type is the
same
as the adapter, the adapter invokes the target as with invokeExact.
(This is the normal behavior for invoke when types match.)
Otherwise, if the caller and adapter arity are the same, and the
trailing parameter type of the caller is a reference type
identical to
or assignable to the trailing parameter type of the adapter, the
arguments and return values are converted pairwise, as if by
asType on a
fixed arity method handle.
Otherwise, the arities differ, or the adapter's trailing parameter
type
is not assignable from the corresponding caller type. In this
case, the
adapter replaces all trailing arguments from the original trailing
argument position onward, by a new array of type arrayType, whose
elements comprise (in order) the replaced arguments."
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)
Hi,
Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden
annotation?
I suspect it has to do with hiding the call frames in stack traces that
are part of LambdaForm invocation chain. In this case, method:
private static Object[] prepend(Object elem, Object[] array)
in MethodHandleImpl need not be annotated with this annotation, since
it's call frame is not on stack when one of the target methods is
executed. It's just a function used to calculate the argument of the
call. In fact, if prepend() ever throws exception (NPE in case array is
null?), It would be preferable that it's call frame is visible in the
stack trace.
Am I right or am I just talking nonsense?
Regards, Peter
On 03/11/2014 12:12 AM, Vladimir Ivanov wrote:
John, Chris, thanks!
Best regards,
Vladimir Ivanov
On 3/11/14 3:08 AM, Christian Thalinger wrote:
Even better.
On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov
wrote:
Chris, thanks for the review.
John suggested an elegant way to fix the problem - use asFixedArity.
Updated fix:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/
Best regards,
Vladimir Ivanov
On 3/8/14 4:51 AM, Christian Thalinger wrote:
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target,
Object... args) throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8036117
84 lines changed: 74 ins; 3 del; 7 mod
I have to revert a cleanup I did for 8027827.
MethodHandle.invokeWithArguments (and generic invocation) has
unpleasant
peculiarity in behavior when used with VarargsCollector. So,
unfortunately, invokeWithArguments is not an option there.
Looking at the API (excerpts from javadoc [1] [2]), the following
condition doesn't hold in that case:
"trailing parameter type of the caller is a reference type
identical
to or assignable to the trailing parameter type of the adapter".
Example:
target.invokeWithArguments((Object[])args)
=>
target.invoke((Object)o1,(Object)o2,(Object)o3)
=/>
target.invokeExact((Object)o1, (Object)o2, (Object[])o3)
because Object !<: Object[].
The fix is to skip unnecessary conversion when invoking a method
handle
and just do a pairwise type conversion.
Testing: failing test case, nashorn w/ experimental features (octane)
Thanks!
Best regards,
Vladimir Ivanov
[1] MethodHandle.invokeWithArguments
"Performs a variable arity invocation, ..., as if via an inexact
invoke
from a call site which mentions only the type Object, and whose
arity is
the length of the argument array."
[2] MethodHandle.asVarargsCollector
"When called with plain, inexact invoke, if the caller type is the
same
as the adapter, the adapter invokes the target as with invokeExact.
(This is the normal behavior for invoke when types match.)
Otherwise, if the caller and adapter arity are the same, and the
trailing parameter type of the caller is a reference type
identical to
or assignable to the trailing parameter type of the adapter, the
arguments and return values are converted pairwise, as if by
asType on a
fixed arity method handle.
Otherwise, the arities differ, or the adapter's trailing parameter
type
is not assignable from the corresponding caller type. In this
case, the
adapter replaces all trailing arguments from the original trailing
argument position onward, by a new array of type arrayType, whose
elements comprise (in order) the replaced arguments."
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems
Another problem with links would be that not all file systems support links. Regards, Volker On Mon, Mar 10, 2014 at 10:34 PM, Brian Burkhalter wrote: > > On Mar 10, 2014, at 2:24 PM, Steven Schlansker wrote: > >>> D) Bidirectional: Java 9 and pre-9 preferences would be kept in sync. >> >> If the scope of the change remains to naming only (leaving the file format >> the same), > > It is almost naming only; see below. > >> it may be possible to >> implement option D via linking - either hard links or symlinks - preserving >> bidirectional compatibility >> without the need for an explicit sync operation. > > Interesting possibility but I don't know that it would work. Consider the > case where Java 9+ creates some preferences on a system where none existed > before. As it does not want to create anything using the old encoding, then > any subsequently run Java 8- instance will not detect the new preferences. > Also, since Java 8- would not understand the newer encoding, the entries > could not be stored in the same tree as this would cause an exception when a > Java 8- instance attempted to read them. > > If I missed something altogether, please elaborate. > > Thanks, > > Brian
Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
Brian, Could you share your benchmarks? On 03/04/2014 04:14 AM, Brian Burkhalter wrote: Hello all, This review request concerns this issue and proposed patch: issue https://bugs.openjdk.java.net/browse/JDK-6375303 patch http://cr.openjdk.java.net/~bpb/6375303/webrev.00/ A review of the current code did not reveal anything clearly amiss in the nature of the the problems which instigated the original filing of this issue. Examination of the code did however suggest some code style and aesthetic improvements as well as a change to how one lazy initialization was implemented (here we go again ...). Summary: - clean up imports section - add AtomicReferenceFieldUpdater-type constant for stringCache initialization - change some existing static final constants to conform to Java coding style - change name of some local variables so as not to hide instance variables of the same name - add missing @Override annotations - modify lazy initialization of stringCache in toString() to use AtomicReferenceFieldUpdater constant - various other minor cleanup Note that the performance of initialization of stringCache was measured for the extant double-checked locking approach, an AtomicReference, and the AtomicReferenceFieldUpdater and no significant degradation was observed for either of the latter versus the baseline for 1 and 4 threads. The updater has the advantage of adding only one object per class as opposed to one per instance. Thanks, Brian -- Best regards, Sergey Kuksenko
Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
Brian, Mike. Could you explain what is the problem with the old caching? String is immutable, BigDecimal is immutable. So we have data race at that place, but it is safe data race. What is the problem if we create several identical strings? You are making stringCache volatile -> performance penalty on ARM & PPC. Setting cache via CAS -> performance penalty everywhere. If you insist to use AtomicFieldUpdater - the better way is to use lazySet, not CAS. On 03/04/2014 09:21 PM, Mike Duigou wrote: On Mar 4 2014, at 07:13 , Peter Levart wrote: On 03/04/2014 01:14 AM, Brian Burkhalter wrote: - add AtomicReferenceFieldUpdater-type constant for stringCache initialization Hi Brian, By using volatile read and CAS, there's still a chance that multiple concurrent threads will be invoking the layoutChars(true) concurrently, but you guarantee that only a single instance of String will ever be returned as a result of the toString() method. Is that what you were pursuing? Yes. (I provided the AtomicReferenceFieldUpdater code). The previous implementation had a benign data race that could result in a later layoutChars result replacing an earlier result and multiple string instances being returned. The new implementation, at small cost, prevents multiple different instances from being returned. Mike -- Best regards, Sergey Kuksenko
