Description:
------------
Hello,

I have came accross this issue after we have recieved random complains for 500ISE errors, which are solved after increasing  opcache.interned_strings_buffer value.

Through series of tests, it seems that the memory set for opcache.interned_strings_buffer is filled the first time the opcache cache files are created and then if the value set for opcache.interned_strings_buffer is changed, the same amount of memory is requested as the first run. 
Clearing up the opcache file_cache restarts the above described process.

This leads to unexpected behaviour:
  * if the value is changed to smaller then the initial value -> most likely the site will not load and will return various errors. It seems the cached files are loaded from the opcache code, until the memory is filled ( set by the smaller value ) and just doesn't load the whole application.
  * if the value is changed to bigger then the initial value -> the opcache uses the same amount of memory for interned_strings_buffer as the initial run.
  * 

This is produced in this environment:
 * shared hosting, where the users applications are kept and loaded from /home/USER/
 * opcache file_cache is stored in /home/USER/.opcache
 * install a application which will take more then 3MB of the interned_strings_buffer memory. Observe with opcache_get_status() the interned_strings_buffer usage 
    ** Here I am using a default WP install, add some big plugings so it has enough modiles/classes to load and somewhere in the code to print out opcache_get_status().
 * Set interned_strings_buffer to 4MB and load the application - the interned_strings_buffer memory usage would be somewhere between 3MB and 4MB.
 * Set interned_strings_buffer to 2MB - it should break ( most often - not able to load some class or 500ISE ).

 * Clear /home/USER/.opcache/ files.
 * Set interned_strings_buffer to 2MB and again observe its usage the same way as above - it uses all 2MB ( with a few bytes left free ).
 * Set interned_strings_buffer to 16MB and again observe its usage - it uses exactly the same amount of memory as the first run ~ 2MB.
 

For the tests I was using opcache.memory_consumption with values 64/128/256.

Tested on PHP versions 7.0.22 and 7.1.8.

I am not sure this a bug in the opcache, but certainly doesn't seem to be expected behaviour.

Regards,
Ilian.