Return-Path: Delivered-To: apmail-harmony-commits-archive@www.apache.org Received: (qmail 29910 invoked from network); 21 May 2008 14:56:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 May 2008 14:56:19 -0000 Received: (qmail 59515 invoked by uid 500); 21 May 2008 14:56:20 -0000 Delivered-To: apmail-harmony-commits-archive@harmony.apache.org Received: (qmail 59500 invoked by uid 500); 21 May 2008 14:56:20 -0000 Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list commits@harmony.apache.org Received: (qmail 59489 invoked by uid 99); 21 May 2008 14:56:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2008 07:56:19 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2008 14:55:34 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id B26B4234C11E for ; Wed, 21 May 2008 07:55:55 -0700 (PDT) Message-ID: <1525955863.1211381755729.JavaMail.jira@brutus> Date: Wed, 21 May 2008 07:55:55 -0700 (PDT) From: "Nathan Beyer (JIRA)" To: commits@harmony.apache.org Subject: [jira] Commented: (HARMONY-5829) [drlvm][kernel][performance] j.l.Class Serializable/Externalizable caching In-Reply-To: <681064225.1210881775738.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HARMONY-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598677#action_12598677 ] Nathan Beyer commented on HARMONY-5829: --------------------------------------- I don't think it's overkill, I think it's correct. After reviewing the memory model, I believe the fields needs to be volatile, at least 'resolvedProperties' field and use the appropriate access paradigms for volatile fields [1]. [1] http://www.ibm.com/developerworks/java/library/j-jtp06197.html#2.0 > [drlvm][kernel][performance] j.l.Class Serializable/Externalizable caching > -------------------------------------------------------------------------- > > Key: HARMONY-5829 > URL: https://issues.apache.org/jira/browse/HARMONY-5829 > Project: Harmony > Issue Type: Sub-task > Components: DRLVM > Reporter: Aleksey Shipilev > Assignee: Pavel Pervov > Attachments: vm-kernel-serializable-externalizable-cache-rc1.patch, vm-kernel-serializable-externalizable-cache-rc2.patch > > > Serialization workloads relies on Class.isAssignableFrom(...) when looking up Serializable and Externalizable properties (that is, implementation of interfaces). For now, DRLVM kernel classes perform lookups on each invocation. This issue caches the mentioned properties in Class fields and does not go to native VMClassRegistry for resolution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.