Bugfix to ensure that logging can be achieved from any thread

[adamretter]

In our application build atop RocksDB we would occasionally see SIGSEGV when background flushes were run.

This was caused by the call to env->FindClass("org/rocksdb/InfoLogLevel") in portal.h returning nullptr. That would happen if the thread calling that was not known to the JVM, e.g. it was created from C++ by pthread_create or similar, calling FindClass from that unknown thread means the JVM cannot find the classloader and so does not locate the class. See also http://developer.android.com/training/articles/perf-jni.html#faq_FindClass

This PR fixes that by caching Global References to the objects that are needed for logging when the logger is first instantiated.

For reference, the SIGSEGV's that we were seeing looked like:

Stack: [0x0000700000097000,0x0000700000117000],  sp=0x00007000001146e0,  free space=501k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x31a1b8]  jni_GetStaticFieldID+0xa7
C  [librocksdbjni2569710166383072200.jnilib+0x3fd7]  rocksdb::InfoLogLevelJni::getEnum(JNIEnv_*, char const*)+0x147
C  [librocksdbjni2569710166383072200.jnilib+0x39cd]  rocksdb::LoggerJniCallback::Logv(rocksdb::InfoLogLevel, char const*, __va_list_tag*)+0xcd
C  [librocksdbjni2569710166383072200.jnilib+0x1b8890]  rocksdb::Log(rocksdb::InfoLogLevel, rocksdb::Logger*, char const*, ...)+0xd0
C  [librocksdbjni2569710166383072200.jnilib+0x259aa6]  rocksdb::LogBuffer::FlushBufferToLog()+0xd6
C  [librocksdbjni2569710166383072200.jnilib+0xd4fdd]  rocksdb::FlushJob::WriteLevel0Table(rocksdb::autovector<rocksdb::MemTable*, 8ul> const&, rocksdb::VersionEdit*, rocksdb::FileMetaData*)+0xcd
C  [librocksdbjni2569710166383072200.jnilib+0xd468a]  rocksdb::FlushJob::Run(rocksdb::FileMetaData*)+0x2fa
C  [librocksdbjni2569710166383072200.jnilib+0x856c6]  rocksdb::DBImpl::FlushMemTableToOutputFile(rocksdb::ColumnFamilyData*, rocksdb::MutableCFOptions const&, bool*, rocksdb::JobContext*, rocksdb::LogBuffer*)+0x2c6
C  [librocksdbjni2569710166383072200.jnilib+0x8de44]  rocksdb::DBImpl::BackgroundFlush(bool*, rocksdb::JobContext*, rocksdb::LogBuffer*)+0x284
C  [librocksdbjni2569710166383072200.jnilib+0x8d0eb]  rocksdb::DBImpl::BackgroundCallFlush()+0x2bb
C  [librocksdbjni2569710166383072200.jnilib+0x1c5800]  rocksdb::ThreadPool::BGThread(unsigned long)+0x120
C  [librocksdbjni2569710166383072200.jnilib+0x1c5bd3]  rocksdb::BGThreadWrapper(void*)+0x23
C  [libsystem_pthread.dylib+0x399d]  _pthread_body+0x83
C  [libsystem_pthread.dylib+0x391a]  _pthread_body+0x0
C  [libsystem_pthread.dylib+0x1351]  thread_start+0xd
C  0x0000000000000000

[siying]

There seems to be a merge error. Java build is broken:

java/rocksjni/loggerjnicallback.cc: In member function ‘virtual void rocksdb::LoggerJniCallback::Logv(rocksdb::InfoLogLevel, const char_, _va_list_tag)’:
java/rocksjni/loggerjnicallback.cc:83:7: error: duplicate case value
case rocksdb::InfoLogLevel::WARN_LEVEL:
^
java/rocksjni/loggerjnicallback.cc:80:7: error: previously used here
case rocksdb::InfoLogLevel::WARN_LEVEL:
^
java/rocksjni/loggerjnicallback.cc:84:50: error: ‘env’ was not declared in this scope
jlog_level = InfoLogLevelJni::WARN_LEVEL(env);
^
java/rocksjni/loggerjnicallback.cc:95:7: error: duplicate case value
case rocksdb::InfoLogLevel::HEADER_LEVEL:
^
java/rocksjni/loggerjnicallback.cc:92:7: error: previously used here
case rocksdb::InfoLogLevel::HEADER_LEVEL:
^