They can be encoded either in the call site name, or in the static parameters to the bootstrap method, or combination thereof ��� whatever makes most sense for the language runtime being implemented! Both emitting invokedynamic instructions and their bootstrapping are responsibilities that always remain within a single language runtime, so there���s no need for enforcing an encoding in the Dynalink specification. The ultimate beauty of the approach? We no longer need to prescribe how should the operations be encoded in the invokedynamic instructions! Nashorn can choose to encode the operations in the bytecode any way it wants, it just needs to decode them accordingly in the bootstrap method. Named operations (mostly, getProp/setProp carrying their property name) could be expressed as ���class NamedOperation implements Operation��� expressing a pair of (Operation, String). it���d just have an "Operation getOperation()��� method. So a CallSiteDescriptor constructor could look like this: CallSiteDescriptor(Lookup lookup, Operation operation, MethodType methodType) and instead of the funky business with getNameToken() etc. For Dynalink composite operations, we can have a ���class CompositeOperation implements Operation" class to express a composition of e.g. So we could have an empty interface named "Operation" in Dynalink with a standard implementation "enum StandardOperation implements Operation" and providing GET_PROPERTY, SET_PROPERTY, GET_ELEMENT, SET_ELEMENT, GET_METHOD, CALL_METHOD, CALL, and NEW values.
We could take a page from the design of which defines a typesafe yet open set of operations for various purposes in its CopyOption and OpenOption interfaces, with standard ones being available as enums implementing the interfaces (StandardCopyOption, StandardOpenOption), but allowing for any additional filesystem-specific ones to extend it see Īs a matter of fact, it looks like accommodating standard but extensible set of operations on diverse filesystems is a problem not unlike accommodating standard but extensible set of operations on diverse object models :-) Upon further thinking, I realized we don���t need a string encoding for the operations at all. Careful redesign may also improve constant parsing time, and therefore contribute to better warmup. This adds up to ~128K characters saved in metaspace memory in Nashorn/Octane case. "D:P|E:xrefstms", which will save ~14 bytes per constant. It seems profitable to condense the control prefixes of these constants to something more dense, e.g. The look of these constants reveals an interesting structure: "dyn:setProp|setElem:xrefstms". That is, around 10% of all symbol space is consumed by "dyn." constants, and the average length of "dyn." constant is around 37 characters.
Sifting through this output yields an interesting observation (the log is sorted and uniq-qed): ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -jar ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/ext/nashorn.jar =false -class-cache-size=0 -persistent-code-cache=false -scripting -log=time test/script/basic/run-octane.js -iterations 1 If you run Nashorn/Octane benchmarks with a simple instrumentation that prints out the symbols looked up from VM's Symbol table.
0 kommentar(er)
