> On Nov 20, 2015, at 1:59 AM, serguei.spit...@oracle.com wrote:
>
> The 'int bci' is not used above.
This is weird. Daniel caught that and I took that line out already.
http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.03-delta/hotspot/src/share/vm/classfile/javaClasses.cpp.sdiff.html
A
On 20/11/15 03:13, Mandy Chung wrote:
Cross-posting to core-libs-dev.
Delta webrev incorporating feedback from Coleen and Brent and also a fix that
Daniel made:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.03-delta/
Full webrev:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/w
On 11/20/15 08:39, Mandy Chung wrote:
On Nov 20, 2015, at 1:59 AM, serguei.spit...@oracle.com wrote:
The 'int bci' is not used above.
This is weird. Daniel caught that and I took that line out already.
http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.03-delta/hotspot/src/share/vm/class
Somehow some of the formatting in my reply is gone.
I'm trying to fix it below...
Thanks,
Serguei
On 11/20/15 01:59, serguei.spit...@oracle.com wrote:
Hi Mandy,
It looks pretty good to me.
At least, I do not see any obvious issues.
Just some minor comments below.
webrev.03/hotspot/src/s
Hi Mandy,
It looks pretty good to me.
At least, I do not see any obvious issues.
Just some minor comments below.
webrev.03/hotspot/src/share/vm/classfile/javaClasses.cpp
2128 Symbol* java_lang_StackFrameInfo::get_file_name(Handle stackFrame,
InstanceKlass* holder) {
2129 if (MemberNameInS
:12
To: Timo Kinnunen;John Rose
Cc: OpenJDK Dev list
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 19/11/2015 11:36 PM, Timo Kinnunen wrote:
> A point in favor of UnsupportedOperationException would be: if in the
> future it becomes possible to have large parts of the JVM writ
Cross-posting to core-libs-dev.
Delta webrev incorporating feedback from Coleen and Brent and also a fix that
Daniel made:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.03-delta/
Full webrev:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.03/
This also includes a couple of
LinkId=550986> for
Windows 10
*From: *John Rose
*Sent: *Thursday, November 19, 2015 05:45
*To: *David Holmes
*Cc: *OpenJDK Dev list
*Subject: *Re: Proposed API for JEP 259: Stack-Walking API
On Nov 18, 2015, at 6:32 PM, David Holmes wrote:
>
>>>
>>> Looks good to me
: John Rose
Sent: Thursday, November 19, 2015 05:45
To: David Holmes
Cc: OpenJDK Dev list
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On Nov 18, 2015, at 6:32 PM, David Holmes wrote:
>
>>>
>>> Looks good to me too if IllegalStateExcepti
On Nov 18, 2015, at 6:32 PM, David Holmes wrote:
>
>>>
>>> Looks good to me too if IllegalStateException is used instead of
>>> UnsupportedOperationException.
>>> UnsuppportedOperationException is used when the operation is not
>>> available, here, the same code can work or not depending how it
> On Nov 18, 2015, at 6:32 PM, David Holmes wrote:
>
>
> I agree with Remi. "state" doesn't have to mean fields - there are numerous
> existing examples in the JDK. Calling a method in a context that is invalid
> is an illegal state to me. IllegalThreadStateException would also work. But
> U
On 18/11/2015 10:26 PM, Peter Levart wrote:
On 11/18/2015 12:22 PM, Remi Forax wrote:
- Mail original -
De: "David Holmes"
À: "Mandy Chung" , "Peter Levart"
Cc: "OpenJDK Dev list"
Envoyé: Mercredi 18 Novembre 2015 08:58:56
Objet: Re: Propose
On 11/18/15 2:24 PM, Mandy Chung wrote:
==
>jdk/src/java.base/share/classes/java/lang/StackFrameInfo.java
>
>66
>Perhaps this.memberName does not need to be allocated in the case of
-XX:-MemberNameInStackFrame ?
>
For more accurate footprint comparison, yes it should not allocate MemberName.
> On Nov 18, 2015, at 1:01 PM, Coleen Phillimore
> wrote:
>
>
> One of the things that I'm struggling with is that StackFrameInfo contains
> both the collected information from walking the stack frames, method id, bci,
> mirror, version and cpref, and the digested information: interned strin
I want to make sure the key point is getting across.
This change does not change anything in Throwable, backtrace and
StackTraceElement. StackFrameInfo is used by the new StackWalker API. JDK
Thread::dumpStack, Thread::getStackTrace and LogRecord/PlatformLogger are
updated to use the stack wa
On 11/18/15 5:06 PM, Mandy Chung wrote:
On Nov 18, 2015, at 1:01 PM, Coleen Phillimore
wrote:
One of the things that I'm struggling with is that StackFrameInfo contains both
the collected information from walking the stack frames, method id, bci,
mirror, version and cpref, and the digeste
> On Nov 18, 2015, at 11:00 AM, Brent Christian
> wrote:
>
> Hi, Mandy
>
> I looked through the jdk code. I think it's looking quite good. I just
> noticed some small details to consider fixing up before pushing.
>
> Docs:
>
> StackWalker.StackFrame.getClassName():
> the "binary name" lin
One of the things that I'm struggling with is that StackFrameInfo
contains both the collected information from walking the stack frames,
method id, bci, mirror, version and cpref, and the digested information:
interned string for class name, method name, line number and source file
name.
If
Hi, Mandy
I looked through the jdk code. I think it's looking quite good. I just
noticed some small details to consider fixing up before pushing.
Docs:
StackWalker.StackFrame.getClassName():
the "binary name" link seems to be broken
(StackWalker.java line 100)
StackWalker.getInstance(Set o
state seems natural
> to me.
>
> Rémi
>
> - Mail original -
>> De: "Peter Levart"
>> À: "Remi Forax" , "David Holmes"
>> Cc: "Mandy Chung" , "OpenJDK Dev list"
>>
>> Envoyé: Mercredi 18 No
This is the update javadoc of getCallerClass. Thanks for all the feedback and
suggestion. I have to finalize this API today to make the FC date :)
/**
* Gets the {@code Class} object of the caller invoking the method
* that calls this {@code getCallerClass} method.
*
* Reflection frames,
> On Nov 18, 2015, at 1:11 AM, Peter Levart wrote:
>
> Hi Mandy,
>
> Just one nit...
>
> On 11/17/2015 11:59 PM, Mandy Chung wrote:
>>> Apart from the orphaned paragraph fragment at the end looks good to me, but
>>> that’s just my opinion.
>> I caught that that after I clicked sent :(
>>
>>
Envoyé: Mercredi 18 Novembre 2015 13:26:32
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
>
>
> On 11/18/2015 12:22 PM, Remi Forax wrote:
> > - Mail original -
> >> De: "David Holmes"
> >> À: "Mandy Chung" , "
- Mail original -
> De: "David Holmes"
> À: "Mandy Chung" , "Peter Levart"
>
> Cc: "OpenJDK Dev list"
> Envoyé: Mercredi 18 Novembre 2015 08:58:56
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
> On 18/11/20
On 11/18/2015 12:22 PM, Remi Forax wrote:
- Mail original -
De: "David Holmes"
À: "Mandy Chung" , "Peter Levart"
Cc: "OpenJDK Dev list"
Envoyé: Mercredi 18 Novembre 2015 08:58:56
Objet: Re: Proposed API for JEP 259: Stack-Walking API
On 18
Hi Mandy,
Just one nit...
On 11/17/2015 11:59 PM, Mandy Chung wrote:
Apart from the orphaned paragraph fragment at the end looks good to me, but
that’s just my opinion.
I caught that that after I clicked sent :(
This is a better version.
/**
* Gets the {@code Class} object of the caller i
) {}).start();
).
Apart from the orphaned paragraph fragment at the end looks good to me, but
that’s just my opinion.
Sent from Mail for Windows 10
From: Mandy Chung
Sent: Tuesday, November 17, 2015 23:43
To: Peter Levart
Cc: OpenJDK Dev list
Subject: Re: Proposed API for JEP 259: Stack
> On Nov 17, 2015, at 2:09 PM, Peter Levart wrote:
>
> I think that calling getCallerClass() from implementation of Runnable::run
> should expect it to return a system class. It may be Thread.class or
> ThreadPoolExecutor$Worker.class or anything actually.
>
I’m now convinced that it’s not
On 18/11/2015 8:42 AM, Mandy Chung wrote:
On Nov 17, 2015, at 2:09 PM, Peter Levart wrote:
I think that calling getCallerClass() from implementation of Runnable::run
should expect it to return a system class. It may be Thread.class or
ThreadPoolExecutor$Worker.class or anything actually.
> On Nov 17, 2015, at 1:13 PM, Peter Levart wrote:
>
> But (as described in my other message), Runnable::run is not an entry point.
> Thread::run is. And Thread::run (a Java method) delegates to Runnable::run.
> So in this case Thread.class will be returned as a normal caller (which it
> real
On Nov 17, 2015, at 4:00 PM, Ian Rogers wrote:
>
> Should the StackWalker.StackFrame interface provide a way to get the
> java.lang.reflect.Method/Constructor/Member?
>
Not in the scope of this JEP.
Mandy
> Thanks,
> Ian
>
> On Tue, Nov 17, 2015 at 3:56 PM, Mandy Chung wrote:
> Thanks Pete
Thanks Peter.
> - threre's no ResourceBundle.getBundle(String, ClassLoader) method.
> - Util -> ResourceBundleUtil (or ResourceBundleUtil -> Util)
>
Fixed.
> :
> - Stream.findFirst() returns Optional, not E.
>
Fixed.
I updated javadoc for getCallerClass per our discussion.
/**
* Gets the
On 11/17/2015 09:50 PM, Mandy Chung wrote:
On Nov 17, 2015, at 11:54 AM, Peter Levart wrote:
On 11/16/2015 08:16 PM, Mandy Chung wrote:
On Nov 15, 2015, at 10:59 AM, Peter Levart
wrote:
OTOH in the described cases, a caller of walker.getCallerClass() is actually expecting to be called
Hi Mandy,
On 11/17/2015 01:13 AM, Mandy Chung wrote:
I’d like to get the code review done by this week.
I renamed the static factory method from create to getInstance since “create”
implies to create a new instance but the method returns a cached instance
instead. I also changed the spec of
> Apart from the orphaned paragraph fragment at the end looks good to me, but
> that’s just my opinion.
I caught that that after I clicked sent :(
This is a better version.
/**
* Gets the {@code Class} object of the caller invoking the method
* that calls this {@code getCallerClass} method.
On 17/11/15 01:13, Mandy Chung wrote:
I’d like to get the code review done by this week.
I renamed the static factory method from create to getInstance since “create”
implies to create a new instance but the method returns a cached instance
instead. I also changed the spec of getCallerClass p
On 11/17/2015 10:13 PM, Peter Levart wrote:
I will keep returning the thread’s entry point case to return the class of the
runnable instead of returning Thread.class.
But (as described in my other message), Runnable::run is not an entry
point. Thread::run is. And Thread::run (a Java metho
> On Nov 17, 2015, at 11:54 AM, Peter Levart wrote:
>
>
>
> On 11/16/2015 08:16 PM, Mandy Chung wrote:
>>> On Nov 15, 2015, at 10:59 AM, Peter Levart
>>> wrote:
>>>
>>> OTOH in the described cases, a caller of walker.getCallerClass() is
>>> actually expecting to be called by a Java method,
> On Nov 17, 2015, at 10:42 AM, Daniel Fuchs wrote:
>
> On 17/11/15 01:13, Mandy Chung wrote:
>> I’d like to get the code review done by this week.
>>
>> I renamed the static factory method from create to getInstance since
>> “create” implies to create a new instance but the method returns a c
On 11/16/2015 08:16 PM, Mandy Chung wrote:
On Nov 15, 2015, at 10:59 AM, Peter Levart wrote:
OTOH in the described cases, a caller of walker.getCallerClass() is actually expecting to be called
by a Java method, right? So what would it be if such "caller-sensitive" method demanded
to be call
I’d like to get the code review done by this week.
I renamed the static factory method from create to getInstance since “create”
implies to create a new instance but the method returns a cached instance
instead. I also changed the spec of getCallerClass per [1]. There is not much
change since
On 11/16/2015 06:13 PM, Mandy Chung wrote:
I’d like to get the code review done by this week.
I renamed the static factory method from create to getInstance since “create”
implies to create a new instance but the method returns a cached instance
instead. I also changed the spec of getCallerCl
> On Nov 16, 2015, at 1:36 AM, Daniel Fuchs wrote:
>
> Hi Mandy,
>
> Sorry I was not clear.
> I'm proposing the following changes:
>
> StackFrameInfo.java:
>
> 100 public OptionalInt getLineNumber() {
> 101 ensureMethodInfoInitialized();
> 102 return lineNumber != -1 && l
ffect at the time it is called.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Peter Levart
> Sent: Sunday, November 15, 2015 20:15
> To: Timo Kinnunen;David M. Lloyd;core-libs-dev@openjdk.java.net
> Subject: Re: Proposed API for JEP 259: Stack-Walking API
> On Nov 15, 2015, at 10:59 AM, Peter Levart wrote:
>
> OTOH in the described cases, a caller of walker.getCallerClass() is actually
> expecting to be called by a Java method, right? So what would it be if such
> "caller-sensitive" method demanded to be called by a Java method and throw
> Ill
Hi Mandy,
Sorry I was not clear.
I'm proposing the following changes:
StackFrameInfo.java:
100 public OptionalInt getLineNumber() {
101 ensureMethodInfoInitialized();
102 return lineNumber != -1 && lineNumber != -2
? OptionalInt.of(lineNumber)
From: Peter Levart
Sent: Sunday, November 15, 2015 20:15
To: Timo Kinnunen;David M. Lloyd;core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 11/15/2015 05:53 PM, Timo Kinnunen wrote:
To be pedantic, there is always a caller, but not every caller is
ch situations.
Regards, Peter
Sent from Mail for Windows 10
From: David M. Lloyd
Sent: Saturday, November 14, 2015 16:02
To: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 11/13/2015 06:07 PM, Brian Goetz wrote:
I considered Optional>. I belie
Hi again,
On 11/15/2015 11:12 AM, Peter Levart wrote:
Hi Mandy,
On 11/15/2015 12:52 AM, Mandy Chung wrote:
I have been thinking what the users would do when there is no caller.
The JDK use of getCallerClass are to:
1. find the caller's class loader for class loader hierarchy check
2. find th
ker::getCallerClass and further suggests
StackWalker::getCaller should be available for clients as well.
Sent from Mail for Windows 10
From: David M. Lloyd
Sent: Saturday, November 14, 2015 16:02
To: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 11
Hi Mandy,
On 11/15/2015 12:52 AM, Mandy Chung wrote:
I have been thinking what the users would do when there is no caller.
The JDK use of getCallerClass are to:
1. find the caller's class loader for class loader hierarchy check
2. find the caller’s class loader to load something on behalf of t
> On Nov 14, 2015, at 7:01 AM, David M. Lloyd wrote:
>
> On 11/13/2015 06:07 PM, Brian Goetz wrote:
>>> I considered Optional>. I believe it is rare to have a JNI
>>> attached thread calling StackWalker::getCallerClass from native. Most
>>> common cases will find a caller class. Returning an
On 11/13/2015 06:07 PM, Brian Goetz wrote:
I considered Optional>. I believe it is rare to have a JNI
attached thread calling StackWalker::getCallerClass from native. Most
common cases will find a caller class. Returning an Optional will
force most common uses to handle the case if it’s absent
The comment was incorrect. It should be:
// this was the last frame decoded in the previous batch
Mandy
> On Nov 13, 2015, at 9:36 AM, Daniel Fuchs wrote:
>
> Hi Mandy,
>
> Looking at stackwalk.cpp, I'm puzzled by this comment at line 465:
>
> http://cr.openjdk.java.net/~mchung/jdk9/jep259
> On Nov 13, 2015, at 9:55 AM, Daniel Fuchs wrote:
>
> Hi Mandy,
>
> StackFrameInfo.java:
>
> 100 public OptionalInt getLineNumber() {
> 101 ensureMethodInfoInitialized();
> 102 return lineNumber != -1 ? OptionalInt.of(lineNumber) :
> OptionalInt.empty();
> 103 }
>
>
I considered Optional>. I believe it is rare to have a JNI attached
thread calling StackWalker::getCallerClass from native. Most common cases will find a
caller class. Returning an Optional will force most common uses to handle the case if
it’s absent. It’s a tradeoff that I think it’s bett
Hi Mandy,
StackFrameInfo.java:
100 public OptionalInt getLineNumber() {
101 ensureMethodInfoInitialized();
102 return lineNumber != -1 ? OptionalInt.of(lineNumber) :
OptionalInt.empty();
103 }
If lineNumber is -2 then empty should probably be returned too.
Which m
Hi Mandy,
Looking at stackwalk.cpp, I'm puzzled by this comment at line 465:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.01/hotspot/src/share/vm/prims/stackwalk.cpp.html
463 vframeStream& vfst = anchor.vframe_stream();
464 if (!vfst.at_end()) {
465 vfst.next(); // skip jav
A revised webrev:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.01
javadoc:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
The main change in this version is mostly in the hotspot change to incorporate
Coleen’s suggestion:
1. Move the new Klasses to syst
, November 12, 2015 17:51
To: core-libs-dev@openjdk.java.net
Subject: Re: Code Review for JEP 259: Stack-Walking API
One other kind of stack metadata that is missing (yet is present with
external tools such as jstack etc.) is ancillary data about stack frames
indicating whether the frame holds or
reduction algorithms.
Thanks,
Jason
From: core-libs-dev on behalf of Mandy Chung
Sent: Monday, November 9, 2015 8:32 PM
To: core-libs-dev; hotspot-runtime-...@openjdk.java.net
Subject: Code Review for JEP 259: Stack-Walking API
javadoc:
http://cr.openjd
-libs-dev; hotspot-runtime-...@openjdk.java.net
> Subject: Code Review for JEP 259: Stack-Walking API
>
> javadoc:
>
> http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
>
> webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/
> On Nov 10, 2015, at 3:05 AM, Jaroslav Bachorik
> wrote:
>
> Mostly nits and typos.
>
> hotspot/src/share/vm/classfile/javaClasses.cpp
> L1941 - variable 'cpref' is not used
>
Fixed.
> hotspot/src/share/vm/classfile/javaClasses.inline.hpp
> L117 - line number 'bci + 100' has a special
> On Nov 10, 2015, at 6:05 AM, Dmitry Samersoff
> wrote:
>
> Mandy,
>
> Native part looks good for me.
>
> javaClasses.cpp:
>
> 1. It might be good to create a helper inline function for
>
> int bci_version = stackFrame->int_field(bci_offset);
> int version = BackTrace::version_at(bci
> On Nov 10, 2015, at 1:07 AM, Peter Levart wrote:
>
> Hi Mandy,
>
> On 11/10/2015 03:20 AM, Mandy Chung wrote:
>> I have updated the APIs to incorporate all the feedback. Thank you all.
>> Let me know if I miss any.
>>
>> Summary:
>> 1. Change to use wildcard walk(Function, ?
>> extends
Mandy,
Native part looks good for me.
javaClasses.cpp:
1. It might be good to create a helper inline function for
int bci_version = stackFrame->int_field(bci_offset);
int version = BackTrace::version_at(bci_version);
2. java_lang_StackFrameInfo::fill_methodInfo
CHECK macro left meth
Hi Mandy,
On 11/10/2015 03:20 AM, Mandy Chung wrote:
I have updated the APIs to incorporate all the feedback. Thank you all. Let
me know if I miss any.
Summary:
1. Change to use wildcard walk(Function, ? extends
T> function)
2. Removed the walk method taking IntUnaryOperator batchSizeMapper
javadoc:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
webrev:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/
Overview of the implementation:
When stack walking begins, the StackWalker calls into the VM to anchor a native
frame (callStackWalk) that
I have updated the APIs to incorporate all the feedback. Thank you all. Let
me know if I miss any.
Summary:
1. Change to use wildcard walk(Function, ? extends
T> function)
2. Removed the walk method taking IntUnaryOperator batchSizeMapper argument
3. Add the new static factory method to cre
Hi Mandy,
My recommendation is to go with with PECS whenever possible, even if some
aspects are redundant.
Paul.
> On 5 Nov 2015, at 22:48, Mandy Chung wrote:
>
>
>> On Nov 4, 2015, at 5:00 AM, Remi Forax wrote:
>>
>>>
>>> Good point. Damn, i don’t like wildcards :-)
>>>
>>> The followin
2015 23:34
To: Timo Kinnunen;Remi Forax;Paul Sandoz
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 04/11/15 11:19, Timo Kinnunen wrote:
> Hi,
>
> I tested your version of the wildcard counter and it appears to be
> incompatible wi
ther such example, a bit surprisingly.
So this means you can’t support all clients at the same time.
Sent from Mail for Windows 10
From: Mandy Chung
Sent: Thursday, November 5, 2015 22:49
To: Remi Forax
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking
> On Nov 5, 2015, at 2:43 PM, David M. Lloyd wrote:
>
> On 11/04/2015 07:15 PM, Mandy Chung wrote:
>> [...]
>> For short-circuiting, I also think it’s reasonable to expect the user know
>> how many remaining frames it expects to traverse and it may not need to
>> increase the batch size i.e. i
n, T> function,
IntUnaryOperator sizing) {
and
T powerWalk(Function, ? extends T> function,
IntUnaryOperator sizing) {
Should result in having same applicability.
Maurizio
Sent from Mail for Windows 10
From: Remi Forax
Sent: Wednesday, November 4, 2015 10:04
To: Paul Sandoz
Cc: core-l
- Mail original -
> De: "Mandy Chung"
> À: "Remi Forax"
> Cc: "Paul Sandoz" , core-libs-dev@openjdk.java.net
> Envoyé: Jeudi 5 Novembre 2015 22:48:45
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
>
> > On Nov 4,
On 11/04/2015 07:15 PM, Mandy Chung wrote:
[...]
For short-circuiting, I also think it’s reasonable to expect the user know how
many remaining frames it expects to traverse and it may not need to increase
the batch size i.e. it might not need to update the remainingNeeded over time.
The user
> On Nov 4, 2015, at 5:00 AM, Remi Forax wrote:
>
>>
>> Good point. Damn, i don’t like wildcards :-)
>>
>> The following works fine:
>>
>> static Function, Long> counter() {
>> return Stream::count;
>> }
>>
>> But there could also cases where one is stuck using a wildcard:
>>
>> Fu
> On Nov 4, 2015, at 12:21 AM, Peter Levart wrote:
>
>>
>> I was not thinking of calling StackWalker::getCallerClass from native, but
>> calling some method from native, which then calls
>> StackWalker::getCallerClass. The method itself can not anticipate how it
>> will be called. Most metho
Sorry for the delay getting back to this.
> On Nov 2, 2015, at 4:46 AM, David M. Lloyd wrote:
>
> I think there are two problems with the current approach:
>
> 1. The function for getting the next batch size is not coupled to the
> function actually doing the work. I think it is just as lik
- Mail original -
> De: "Paul Sandoz"
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Mercredi 4 Novembre 2015 10:57:41
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
>
> > On 4 Nov 2015, at 10:03, Remi Forax wrote:
> >
> > Hi
mismatch;
java.util.function.Function,java.lang.Long> cannot
be converted to
java.util.function.Function,T>)
Sent from Mail for Windows 10
From: Remi Forax
Sent: Wednesday, November 4, 2015 10:04
To: Paul Sandoz
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walkin
On 04/11/15 02:59, Mandy Chung wrote:
>
>> On Nov 3, 2015, at 2:08 PM, David M. Lloyd
>> wrote:
>>
>>> I considered Optional>. I believe it is rare to have a
>>> JNI attached thread calling StackWalker::getCallerClass from
>>> native. Most common cases will find a caller class. Returning
>>>
.walk(counter());
regards,
Rémi
- Mail original -
> De: "Paul Sandoz"
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Lundi 2 Novembre 2015 13:44:24
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
> I agree with Maurizio, the first signature is good enough.
>
> On 4 Nov 2015, at 10:03, Remi Forax wrote:
>
> Hi Paul,
>
> The use of BaseStream was just an example, here is another one that works
> only if the function first parameter type is declared as '? super
> Stream'.
>
> static Function, Integer> counter() {
> return stream::count;
> }
>
> .
> On 4 Nov 2015, at 04:50, Mandy Chung wrote:
>
>
>> On Nov 3, 2015, at 3:28 AM, Paul Sandoz wrote:
>>
>> Hi Mandy,
>>
>> This is very nice work.
>>
>> Comments below, mostly minor stuff.
>>
>
> Thanks for the review.
>
> I fixed most of the comments below. One question:
>
> Is the na
On 11/04/2015 09:06 AM, Peter Levart wrote:
What would it be if getCallerClass() returned just
Optional> and was left to the user to decide what to do in
corner cases when there is no Java caller?
I considered Optional>. I believe it is rare to have a JNI
attached thread calling StackWalker
On 11/03/2015 10:33 PM, Mandy Chung wrote:
On Nov 3, 2015, at 4:45 AM, Peter Levart wrote:
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which is described
as equivalent to the following:
walk((s) -> s.map(StackFrame::getDeclaringClass)
> On Nov 3, 2015, at 3:28 AM, Paul Sandoz wrote:
>
> Hi Mandy,
>
> This is very nice work.
>
> Comments below, mostly minor stuff.
>
Thanks for the review.
I fixed most of the comments below. One question:
Is the name “StackStream" inappropriate and its subtypes? I prefer StackStream
t
> On Nov 3, 2015, at 2:08 PM, David M. Lloyd wrote:
>
>> I considered Optional>. I believe it is rare to have a JNI attached
>> thread calling StackWalker::getCallerClass from native. Most common cases
>> will find a caller class. Returning an Optional will force most common
>> uses to han
> On Nov 3, 2015, at 4:45 AM, Peter Levart wrote:
>
> Hi Mandy,
>
> Great API.
>
> One thing I noticed is method StackWalker.getCallerClass() which is described
> as equivalent to the following:
>
> walk((s) -> s.map(StackFrame::getDeclaringClass)
> .skip(2)
> .findFirst()).
On 11/03/2015 03:33 PM, Mandy Chung wrote:
On Nov 3, 2015, at 4:45 AM, Peter Levart wrote:
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which is described
as equivalent to the following:
walk((s) -> s.map(StackFrame::getDeclaringClass)
On 11/03/2015 02:20 PM, Daniel Fuchs wrote:
Hi Peter,
You also get Thread.currentThread().getClass() if you call
StackWalker.getCallerClass() from main().
Because who is the caller of main()?
I would say there is no Java caller in that case and return
Optional.empty().
No Java caller mea
Hi Peter,
You also get Thread.currentThread().getClass() if you call
StackWalker.getCallerClass() from main().
Because who is the caller of main()?
cheers,
-- daniel
On 03/11/15 13:45, Peter Levart wrote:
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which is
described as equivalent to the following:
walk((s) -> s.map(StackFrame::getDeclaringClass)
.skip(2)
.findFirst()).orElse(Thread.currentThread().getClass());
... the .orElse is presumab
Hi Mandy,
This is very nice work.
Comments below, mostly minor stuff.
PlatformLogger.java
(and similar comments for duplicated code in LogRecord.java)
—
542 static final StackWalker stackWalker;
Use capitals for static variable.
556 private boolean lookingForLogger
tober 30, 2015 2:04 PM
> To: core-libs-dev
> Subject: Proposed API for JEP 259: Stack-Walking API
>
> JEP 259: http://openjdk.java.net/jeps/259
>
> Javadoc for the proposed StackWalker API:
>
> http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
&g
n/performance improvement?
Mandy
> Regards,
> Jeroen
>
>> -Original Message-
>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
>> Behalf Of Mandy Chung
>> Sent: Friday, October 30, 2015 20:05
>> To: core-libs-dev
>&
Thanks for the feedback, Paul and Maurizio, that’s very helpful.
I slightly opt for consistency with other areas and go with #2.
Mandy
> On Nov 2, 2015, at 4:44 AM, Paul Sandoz wrote:
>
> I agree with Maurizio, the first signature is good enough.
>
> One could argue that it might be better to
Sent: Friday, October 30, 2015 2:04 PM
To: core-libs-dev
Subject: Proposed API for JEP 259: Stack-Walking API
JEP 259: http://openjdk.java.net/jeps/259
Javadoc for the proposed StackWalker API:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
A simple way to walk
I also agree - when an object type "passes through" a method, it's
usually best to use an invariant type variable.
On 11/02/2015 06:44 AM, Paul Sandoz wrote:
I agree with Maurizio, the first signature is good enough.
One could argue that it might be better to apply PECS since it would encourag
1 - 100 of 127 matches
Mail list logo
