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

[Benjamin Sieffert]

Hello again,

it is always the same script engine being used, and multi-threaded at that.
There is no shared state being manipulated in the javascript, though – the
relevant state of each thread is completely method-scoped. Entry is
therefor not done via eval(), but by using callMember() on an object
previously retrieved from an eval() call.
Another relevant thing here might be that the problematic call itself is a
bit on the expensive side (up to 5ms, mostly under 1ms) and requires some
amount of synchronization (accessing a cache and an in-memory lucene
index). I can't gauge whether this might possibly have any impact on the
linking.

- Benjamin

On 19 November 2014 11:06, Hannes Wallnoefer <hannes.wallnoefer at oracle.com>
wrote:

> Hi Benjamin,
>
> Thanks for the report. There is indeed something going wrong here.
> Ideally, an app would not (or only occasionally) relink once it has
> stabilized.
>
> I think we should be able to reproduce the problem from your description:
> method in abstract class, about a dozen subclasses none of which overwrites
> the original method.
>
> One question: How is the script evaluated? Does all this take place within
> a single script engine eval()? Or are you repeatedly evaluating/calling
> into the script engine?
>
> Thanks,
> Hannes
>
> Am 2014-11-19 um 10:40 schrieb Benjamin Sieffert:
>
>  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
>> class
>> - 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.
>>
>> Regards,
>> Benjamin
>>
>>
>


-- 
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.