On Fri, Oct 5, 2018 at 3:46 PM Luke Hutchison <luke.hu...@gmail.com> wrote:
>
> In my own code, I used StackWalker::forEach rather than StalkWalker::walk,
> since the stream API has such high overhead. Even lambdas have a high
> startup overhead for some reason (I think it was 20ms of incurred latency
> when you first use a lambda, last time I measured it?), but at least
> forEach should deliver much higher throughput than walk.
Maybe. I find it's good to skip lambdas in this case and use a
singleton which implements my walk behavior (when possible).
> The code I'm using currently is below. I have a few questions:
>
> (1) Is it correct to try both StackWalker and SecurityManager first with
> doPrivileged, and then if that fails, without doPrivileged? (i.e. I think
> it is possible for doPrivileged to fail when non-doPrivileged doesn't fail,
> *or* vice versa, depending on the security configuration?) -- sorry for the
> newbie question re. JVM security, I'm having a hard time getting my head
> around it...
No, that would not be correct. It would be correct to always use a
doPrivileged. If the overhead of doPrivileged is a concern (sometimes
it is, sometimes it isn't), then it is common practice (if not
strictly "correct") to first check to see if a security manager is
installed, and if so, use doPrivileged. However, it should be noted
that a single StackWalker can be cached in a static final field for
re-use, as can a single "fake" SecurityManager instance, so I don't
think performance is likely to reasonably be a concern in this
particular case since the amortized cost becomes zero over multiple
usages.
> (2) Is it reasonable to fail over from StackWalker to SecurityManager? Or
> if StackWalker fails due to security limitations, will SecurityManager
> always fail due to the same security limitations? (Are their security
> models a 1:1 match?)
It is theoretically possible for the SecurityManager approach to
succeed if the StackWalker approach fails. However it is exceedingly
unlikely, as it would require a pretty unusual security policy
(specifically, one which grants other code the ability to construct
alternative security managers [including
RuntimePermission("accessClassInPackage.java.lang") plus
RuntimePermission("setSecurityManager")] but does not grant the
ability to construct stack walkers with Class access [just
RuntimePermission("getStackWalkerWithClassReference")]). I wouldn't
worry about that possibility. I think it's pretty reasonable to
document that user programs that wish to have context-sensitive
loggers should grant the "getStackWalkerWithClassReference"
RuntimePermission to the logging JAR/module. I think a single clear
behavior plus a documentation note would result in a better user
experience than falling back through multiple potentially differing
behaviors based on run time factors which may not be immediately clear
to the user.
> (3) Under what circumstances can StackWalker and/or SecurityManager obtain
> more information about a stacktrace than Exception::getStackTrace?
I believe (but am not 100% certain) that the information from
Throwable.getStackTrace is equivalent to that acquired from a
StackWalker that has the SHOW_REFLECT_FRAMES option. I don't recall
the exact circumstances in which the outputs of
SecurityManager.getClassContext() and Throwable.getStackTrace() could
differ, but I do recall that in the Bad Old Days, if one wanted a
unified set of information from both sources, one would need some
hacky heuristic correlation code that would merge the two data sets.
In practice this worked OK but it was ugly code and hard to test. I
believe I deleted the information from my memory the moment
StackWalker became a reality. :)
--
- DML
