RFR 8153123 : Streamline StackWalker code

[Daniel Fuchs]

Hi Brent,

This looks good! Thanks for taking care of this one.

In 
http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/hotspot/src/share/vm/prims/jvm.cpp.frames.html

  548   objArrayOop fa = objArrayOop(JNIHandles::resolve_non_null(frames));
  549   objArrayHandle frames_array_h(THREAD, fa);
  550
  551   int limit = start_index + frame_count;
  552   if (frames_array_h.is_null()) {
  553     THROW_MSG_(vmSymbols::java_lang_IllegalArgumentException(), 
"parameters and mode mismatch", NULL);
  554   }

Can frames_array_h.is_null() ever be true, given that we used
JNIHandles::resolve_non_null(frames) at line 548?
I wonder if lines 552-554 are a remnant of the previous
implementation and could be removed now...


  589   Handle stack_frame_info(THREAD, JNIHandles::resolve(frame));
  590   Handle stack_trace_element(THREAD, JNIHandles::resolve(stack));

Should these call JNIHandles::resolve_non_null instead?


http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/jdk/src/java.base/share/classes/java/lang/StackFrameInfo.java.frames.html

I'd be very tempted to make 'ste' private volatile.


That's all for me :-)

best regards,

-- daniel


On 05/04/16 01:45, Brent Christian wrote:
> Hi,
>
> I'd like to check in some footprint and code reduction changes to the
> java.lang.StackWalker implementation.
>
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8153123
>
> A summary of the changes:
>
> * remove the "stackwalk.newThrowable" system property and
> "MemberNameInStackFrame" VM flag, originally left in to aid benchmarking
>
> * Streamline StackFrameInfo fields
>
> * Refactor/streamline StackStreamFactory (no more separate
> classes[]/StackFrame[] arrays, remove unneeded (for now)
> StackStreamFactory.StackTrace class)
>
>
> Given the hotspot changes, I plan to push this through hs-rt.
>
> Thanks,
> -Brent
>