Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #8470
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Avoid creating a stacktrace prior to JDK 1.7 |
| Date | 2011-10-02 02:04 +0200 |
| Organization | albasani.net |
| Message-ID | <j689qr$6l1$1@news.albasani.net> (permalink) |
| References | (4 earlier) <j67kk4$qf3$1@news.albasani.net> <1058576.2212.1317496868028.JavaMail.geo-discussion-forums@prfh23> <j67rp6$afo$1@news.albasani.net> <j67svg$7om$1@dont-email.me> <j682df$9ve$1@dont-email.me> |
Stanimir Stamenkov schrieb:
> quite wrong!). Virtual machines are allowed to do extensive
> | optimizations when JITing and may entirely remove stack frames,
> | making it impossible to reliably locate the calling class and
> | method.
>
> So it seems stack trace information is not guaranteed to be available to
> user code. This detail may be given somewhere in the language or VM
> specifications.
Yes, you usually don't get a stack overflow
when you do tail recursion for example. So
a method:
void p(int a) {
...
p(b);
}
Is the same as a loop:
void p(int a) {
for (;;) {
...
a = b;
}
}
The simplest obtimisation a JIT can do is replace
the last call p(b) by a jump, so not pushing a
new return address on the stack and reusing the
already pushed return address.
Etc... Etc...
Bye
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-09-30 15:57 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 13:27 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 13:22 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 09:10 -0700
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 20:31 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 20:02 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 12:21 -0700
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 22:04 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-01 16:24 -0400
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 23:14 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-01 17:28 -0400
Re: Avoid creating a stacktrace prior to JDK 1.7 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-01 23:45 +0000
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-02 00:58 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-02 02:04 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 20:06 -0700
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-02 13:14 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-02 08:37 -0700
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-02 20:26 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-02 17:51 -0400
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-03 01:32 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 20:19 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 20:04 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 21:15 +0300
csiph-web