A certain (type of?) callsite seems to always require relinking

Benjamin Sieffert benjamin.sieffert at metrigo.de
Wed Nov 19 09:40:08 UTC 2014

Hello everyone,

it started with a peculiar obversion about our nashorn-utilising
application, that I made: It continues to load around a hundred new
anonymous classes *per second*, even without new scripts being introduced –
i.e. we are just running the same javascripts over and over again, with
different arguments.
So I ran the application with -tcs=miss and from what I see, eventually
there will be only a single call left that is producing all the output and
therefor, I believe, all the memory load. (Am I correct in this assumption?)

What I can say about the call is the following:

- return type is an array of differing length (but always of the same type)
- there are two arguments, of which the first one will always exactly match
the declaration, the second one is a subclass of the one used in the
declaration – but always the same subclass
- method is implemented in an abstract class
- receiver is one of about a dozen classes that inherit from this abstract
- none of the receivers overwrite the original implementation or overload
the method

When I look into the trace output, there's often a bunch of
"TAG MISS library:212 dyn:getMethod|getProp|getElem:<methodname> …"
in a row, then a whole lot of
"TAG MISS library:212
dyn:call([jdk.internal.dynalink.beans.SimpleDynamicMethod …"
with a bit of the first one inbetween.

Is this a known issue? Is there something I can do to alleviate the
problem? As it is, I might just end up implementing the whole chunk in Java
and be done with it, but I thought this might be worthy of some discussion.
If there's some important information that I have left out, I'll be glad to
follow up with it.


Benjamin Sieffert
metrigo GmbH
Sternstr. 106
20357 Hamburg

Geschäftsführer: Christian Müller, Tobias Schlottke, Philipp Westermeyer,
Martin Rieß
Die Gesellschaft ist eingetragen beim Registergericht Hamburg
Nr. HRB 120447.

More information about the nashorn-dev mailing list