> (This is because
> verification is not the hotspot function).
Folks,
JFYI, DRLVM skips verification of the bootstrap classes.
Thanks!
On Tue, Nov 4, 2008 at 10:18 AM, Wenlong Li <[EMAIL PROTECTED]> wrote:
> Mingjian,
>
> Thx for your kind suggestion. I tried the verification bypass approach
> on Harmony, and found it doesn't help performance (This is because
> verification is not the hotspot function).
>
> btw, can you comment more on " some class OS sharing mechanism may
> reduce the second jvm startup
> time?(IBM and SUN JDK 6.0+ seem using this mechanism)", I don't fully
> understand what it means.
>
> Thx, Wenlong
>
>
> I changed the following verification function (in verifier_stub.cpp),
> you can see the new verification is very light-weight.
>
> bool Class::verify(const Global_Env * env) // This is the original
> implementation in Harmony
> {
> // fast path
> if (m_state >= ST_BytecodesVerified)
> return true;
>
> LMAutoUnlock aulock(m_lock);
> if (m_state >= ST_BytecodesVerified)
> return true;
>
> if (is_array()) {
> // no need do bytecode verification for arrays
> m_state = ST_BytecodesVerified;
> return true;
> }
>
> /**
> * Get verifier enable status
> */
> Boolean is_forced = env->verify_all;
> Boolean is_strict = env->verify_strict;
> Boolean is_bootstrap = m_class_loader->IsBootstrap();
> Boolean is_enabled = env->verify;
>
> /**
> * Verify class
> */
> if (is_enabled == 1 && !is_interface()
> && (is_bootstrap == FALSE || is_forced == TRUE)) {
> char *error;
> vf_Result result =
> vf_verify_class(this, is_strict, &error);
> if (VF_OK != result) {
> aulock.ForceUnlock();
> REPORT_FAILED_CLASS_CLASS(m_class_loader, this,
> "java/lang/VerifyError", error);
> vf_release_memory(error);
> return false;
> }
> }
> m_state = ST_BytecodesVerified;
>
> return true;
> } // Class::verify
>
> to
> bool Class::verify(const Global_Env * env) // This is the optimized
> version. It could estimate the verification bypass
> {
> // fast path
> if (m_state >= ST_BytecodesVerified)
> return true;
> m_state = ST_BytecodesVerified;
> return true;
> }
>
> On Tue, Nov 4, 2008 at 1:20 PM, Jin Mingjian <[EMAIL PROTECTED]> wrote:
>> just a note here:
>> From some dynamic language implementors, it is reported that, Sun's
>> jvm may treat the bootstrape classes different. (such as, some
>> verification has been bypassed?)
>>
>> some class OS sharing mechanism may reduce the second jvm startup
>> time?(IBM and SUN JDK 6.0+ seem using this mechanism)
>>
>
--
With best regards,
Alexei