JDK-8216307 : StackTraceElement::fill_in can use existing Module name and version
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,12,13
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2019-01-07
  • Updated: 2019-01-15
  • Resolved: 2019-01-14
Description
This is a subtask of JDK-8151751.

It seems that Module version and name are already available in java.lang.Module::version and java.lang.Module::descriptor -> java.lang.module.ModuleDescriptor.Version::version. Accessing those would require drilling a few new holes in VM symbols and Java classes, and that would remove the need to intern them all the time at stack trace creation. 

Prototype patch:
  http://cr.openjdk.java.net/~shade/8216307/webrev.00/

# 8u192 
StackTraceBench.test 1 avgt 15 10.851 ± 0.075 us/op 
StackTraceBench.test 10 avgt 15 15.325 ± 0.089 us/op 
StackTraceBench.test 100 avgt 15 59.717 ± 0.449 us/op 
StackTraceBench.test 1000 avgt 15 529.020 ± 3.654 us/op 

# jdk/jdk, baseline (with JDK-8216308) 
StackTraceBench.test 1 avgt 15 14.450 ± 0.136 us/op 
StackTraceBench.test 10 avgt 15 20.182 ± 0.088 us/op 
StackTraceBench.test 100 avgt 15 77.107 ± 0.632 us/op 
StackTraceBench.test 1000 avgt 15 647.128 ± 6.159 us/op 

# jdk/jdk, patched 
StackTraceBench.test        1  avgt   15   12.951 ± 0.083  us/op
StackTraceBench.test       10  avgt   15   18.770 ± 0.111  us/op
StackTraceBench.test      100  avgt   15   75.909 ± 0.449  us/op
StackTraceBench.test     1000  avgt   15  640.916 ± 4.088  us/op

The improvement is not much, because the original benchmark does not have lots of frames that go through the named module.
Comments
Further exploration shows a peculiarity in corelib-VM interface. It is possible to define the module that has no "proper" Java versions set, as demonstrated in the regression test that used WhiteBox to define the module for testing. It would seem at this point that drilling new holes and fixing all these corner cases would not outweigh the (small) benefits this patch gives. It also not a particular problem for the non-modularized applications. Therefore, I'd be closing this as WNF. Let's reopen it if parent JDK-8151751 needs more work.
14-01-2019