Hi Aleksey, This is an interesting experiment.
On 3/4/16 8:28 AM, Aleksey Shipilev wrote:
On 03/02/2016 11:21 PM, Aleksey Shipilev wrote:
On 03/02/2016 10:57 PM, Coleen Phillimore wrote:
On 3/2/16 1:58 PM, Aleksey Shipilev wrote:
Is there an underlying reason why we can't return the pre-filled
StackTraceElements[] array from the JVM_GetStackTraceElements to begin
with? This will avoid leaking StackTraceElement constructor into
standard library, *and* allows to make StackTraceElement fields final.
Taking stuff back from the standard library is hard, if not impossible,
so we better expose as little as possible.
We measured that it's faster to allocate the StackTraceElement array
in Java and it seems cleaner to the Java guys. It came from similar
code we've been prototyping for StackFrameInfo.
OK, it's not perfectly clean from implementation standpoint, but this
RFE might not be the best opportunity to polish that. At least make
StackTraceElement constructor private (better), or package-private
(acceptable), and then we are good to go.
Okay, here's a little exploration:
http://cr.openjdk.java.net/~shade/8150778/StackTraceBench.java
The difference between allocating in Java code, and allocating on VM
side is marginal on my machine, but I think we are down to native memset
performance when allocating on VM side. Therefore, I'd probably stay
with Java allocation which codegen we absolutely control.
Thanks for the experiment. We measured a greater performance
difference. The theory is that through Java, allocation is a TLAB
pointer update in most cases, vs going through all the C++ code to do
allocation. The small difference for performance here isn't critical,
but having the allocation in Java looks nicer to the Java programmers here.
Aside: see the last experiment, avoiding StringTable::intern (shows in
profiles a lot!) trims down construction costs down even further. I'd
think that is a worthwhile improvement to consider.
Hm, this is an interesting experiment. I've been looking for a better
way to store the name of the method rather than cpref.
thanks,
Coleen
Cheers,
-Aleksey
