Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
On 03/06/2015 02:30 PM, Staffan Larsen wrote: I would like to backport this bug fix to jdk8 - does anyone see any problems with that? The patch applies cleanly (after shuffling) and the java/lang/invoke/ tests succeed. Thanks, /Staffan I see no problem, quite the opposite, please backport it, nobody like big stack traces. Rémi
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
I would like to backport this bug fix to jdk8 - does anyone see any problems with that? The patch applies cleanly (after shuffling) and the java/lang/invoke/ tests succeed. Thanks, /Staffan
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
1. Are there other places where we generate ACC_SYNTHETIC that should also get @Hidden annotations? Compiler-generated bridge methods?
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
On 02/17/2015 07:54 AM, John Rose wrote: On Feb 16, 2015, at 10:33 PM, Staffan Larsen staffan.lar...@oracle.com wrote: The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The drawback was that the actual lambda method are marked ACC_SYNTHETIC, so that filtered too much. OTOH it seems odd to filter out the actual interface method. Ideally the back trace should show the name of the interface method and the implementation code of the lambda. This information is divided between the two frames in question. That's right. Lambda method is special. It is synthetic, but contains user code. So perhaps lambda method could be annotated with a special annotation (@SyntheticName) to indicate that the name of the method is generated and not interesting, but it's code is written by a programmer and is interesting. If this info was included in the StackTraceElement, then printing the stack trace could merge the byte code location of such element with the class/method name of the subsequent element and print both in one line... The logic behind this is general: if a method name is generated and not interesting (the lambda method), then code calling such method must have been generated too and is consequently not interesting (the proxy method). Peter
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
+1
cheers
/Joel
On 16 Feb 2015, at 15:25, Staffan Larsen staffan.lar...@oracle.com wrote:
Good point!
new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/
Thanks,
/Staffan
On 16 feb 2015, at 12:40, Remi Forax fo...@univ-mlv.fr wrote:
Hi Staffan,
ASM MethodVisitor API requires to call visitAnnotation before calling
visitCode so
I think you shoud call visitAnnotation before calling new
ForwardingMethodGenerator(mv).generate().
cheers,
Rémi
On 02/16/2015 08:47 AM, Staffan Larsen wrote:
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/
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
webrev: 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
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
yes,
thumb up !
Rémi
Le 16 février 2015 18:50:25 CET, Joel Borggrén-Franck
joel.fra...@oracle.com a écrit :
+1
cheers
/Joel
On 16 Feb 2015, at 15:25, Staffan Larsen staffan.lar...@oracle.com
wrote:
Good point!
new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/
Thanks,
/Staffan
On 16 feb 2015, at 12:40, Remi Forax fo...@univ-mlv.fr wrote:
Hi Staffan,
ASM MethodVisitor API requires to call visitAnnotation before
calling visitCode so
I think you shoud call visitAnnotation before calling new
ForwardingMethodGenerator(mv).generate().
cheers,
Rémi
On 02/16/2015 08:47 AM, Staffan Larsen wrote:
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/
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
webrev: 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
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
On Feb 16, 2015, at 6:25 AM, Staffan Larsen staffan.lar...@oracle.com wrote: new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ http://cr.openjdk.java.net/~sla/8025636/webrev.02/ Looks good; ship it. To me this fix raises more questions: 1. Are there other places where we generate ACC_SYNTHETIC that should also get @Hidden annotations? 2. Should the JVM be filtering stack frames for ACC_SYNTHETIC (or ACC_BRIDGE or ACC_MANDATED) calls? (By default? Or perhaps as a new option?) 3. When will we have a reasonable stack walking mechanism where we can program such policies in JDK library code, instead of hacking the JVM? — John P.S. https://bugs.openjdk.java.net/browse/JDK-8043814
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
Good point!
new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/
http://cr.openjdk.java.net/~sla/8025636/webrev.02/
Thanks,
/Staffan
On 16 feb 2015, at 12:40, Remi Forax fo...@univ-mlv.fr wrote:
Hi Staffan,
ASM MethodVisitor API requires to call visitAnnotation before calling
visitCode so
I think you shoud call visitAnnotation before calling new
ForwardingMethodGenerator(mv).generate().
cheers,
Rémi
On 02/16/2015 08:47 AM, Staffan Larsen wrote:
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/%7Esla/8025636/webrev.01/
Thanks,
/Staffan
On 3 feb 2015, at 10:15, Staffan Larsen staffan.lar...@oracle.com
mailto: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/%7Esla/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
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
On 17 feb 2015, at 02:16, John Rose john.r.r...@oracle.com wrote: On Feb 16, 2015, at 6:25 AM, Staffan Larsen staffan.lar...@oracle.com mailto:staffan.lar...@oracle.com wrote: new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ http://cr.openjdk.java.net/~sla/8025636/webrev.02/ Looks good; ship it. Thanks. To me this fix raises more questions: 1. Are there other places where we generate ACC_SYNTHETIC that should also get @Hidden annotations? 2. Should the JVM be filtering stack frames for ACC_SYNTHETIC (or ACC_BRIDGE or ACC_MANDATED) calls? (By default? Or perhaps as a new option?) The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The drawback was that the actual lambda method are marked ACC_SYNTHETIC, so that filtered too much. /Staffan 3. When will we have a reasonable stack walking mechanism where we can program such policies in JDK library code, instead of hacking the JVM? — John P.S. https://bugs.openjdk.java.net/browse/JDK-8043814 https://bugs.openjdk.java.net/browse/JDK-8043814
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
On Feb 16, 2015, at 10:33 PM, Staffan Larsen staffan.lar...@oracle.com wrote: The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The drawback was that the actual lambda method are marked ACC_SYNTHETIC, so that filtered too much. OTOH it seems odd to filter out the actual interface method. Ideally the back trace should show the name of the interface method and the implementation code of the lambda. This information is divided between the two frames in question.
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
Looks good.
Best regards,
Vladimir Ivanov
On 2/16/15 10:47 AM, Staffan Larsen wrote:
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
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
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
Hi, On 03 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 webrev: 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. Parsing of the annotation by core reflection can of course happen but should be fine. AnnotationParser calls into the generics machinery to get a Class instance for the annotation type, this shouldn’t be a problem since Class.forName() doesn’t care about package visibility when handing out Class instances to the best of my understanding. Also the parsing machinery is in the null loader so it will be able to find the type. The Proxy for the annotation also shouldn’t care about the package visibility since there is only one interface being proxied (again to the best of my knowledge). If someone were to access members of the parsed annotation things might start to break, but there are none. Looks good to me, but you should probably get at reviewer that knows the invoke code better. cheers /Joel
RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
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
Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
Looks good for me.
Rémi
Le 3 février 2015 10:15:24 CET, Staffan Larsen staffan.lar...@oracle.com a
écrit :
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
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
