Return-Path: X-Original-To: apmail-felix-dev-archive@www.apache.org Delivered-To: apmail-felix-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D141F11C44 for ; Fri, 25 Jul 2014 14:16:44 +0000 (UTC) Received: (qmail 50249 invoked by uid 500); 25 Jul 2014 14:16:44 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 50174 invoked by uid 500); 25 Jul 2014 14:16:44 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 50163 invoked by uid 99); 25 Jul 2014 14:16:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Jul 2014 14:16:44 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of marcel.offermans@luminis.eu designates 213.199.154.10 as permitted sender) Received: from [213.199.154.10] (HELO emea01-am1-obe.outbound.protection.outlook.com) (213.199.154.10) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Jul 2014 14:16:38 +0000 Received: from DB3PR03MB268.eurprd03.prod.outlook.com (10.242.131.154) by DB3PR03MB266.eurprd03.prod.outlook.com (10.242.131.147) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 14:16:13 +0000 Received: from DB3PR03MB268.eurprd03.prod.outlook.com ([169.254.4.66]) by DB3PR03MB268.eurprd03.prod.outlook.com ([169.254.4.66]) with mapi id 15.00.0990.007; Fri, 25 Jul 2014 14:16:14 +0000 From: Marcel Offermans To: "dev@felix.apache.org" Subject: RE: Java process codepage sharing Thread-Topic: Java process codepage sharing Thread-Index: AQHPqAZfg1hYZ/uo6UuKVB5m5QDAjJuwxmsAgAAEGoCAAAruJQ== Date: Fri, 25 Jul 2014 14:16:13 +0000 Message-ID: <1406297773354.56387@luminis.eu> References: <53D25158.4060002@ascert.com> <53D259AA.2080508@ungoverned.org>,<53D25D1B.3030802@ascert.com> In-Reply-To: <53D25D1B.3030802@ascert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:983:ef07:1:2c45:ac27:1c91:6f4d] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM;SFS:(6009001)(479174003)(377454003)(24454002)(51704005)(199002)(52044002)(189002)(64706001)(4396001)(81342001)(76482001)(86362001)(83072002)(77096002)(110136001)(95666004)(74502001)(106356001)(74662001)(77982001)(81542001)(79102001)(46102001)(76176999)(83322001)(107046002)(87936001)(19580405001)(54356999)(21056001)(85306003)(36756003)(105586002)(19580395003)(85852003)(101416001)(15974865002)(2351001)(74482001)(92726001)(107886001)(2656002)(99396002)(20776003)(80022001)(106116001)(31966008)(50986999)(92566001);DIR:OUT;SFP:;SCL:1;SRVR:DB3PR03MB266;H:DB3PR03MB268.eurprd03.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: luminis.eu X-Virus-Checked: Checked by ClamAV on apache.org You might want to try and contact Jan Rellermeyer about this. Last time I t= alked to him at an OSGi meeting he was looking into doing multi-tenancy bas= ed on codepage sharing. He might have further insights into this.=0A= =0A= Greetings, Marcel=0A= =0A= ________________________________________=0A= From: Rob Walker =0A= Sent: Friday, July 25, 2014 3:35 PM=0A= To: dev@felix.apache.org=0A= Subject: Re: Java process codepage sharing=0A= =0A= On 25/07/2014 15:20, Richard S. Hall wrote:=0A= > On 7/25/14, 08:45 , Rob Walker wrote:=0A= >> I'm being lazy here, but didn't find a quick answer via Google.=0A= >>=0A= >> I have it in the back of my mind that the Java VM has some kind of=0A= >> codepage sharing i.e. 2 java process running the same code on the=0A= >> same machine will only use one memory space for the loaded class=0A= >> bytecode. Each will have it's own data pages clearly.=0A= >>=0A= >> 1st question is - am I correct on this?=0A= >>=0A= >> If this is true it leads to my 2nd question - whether Felix/OSGi=0A= >> defeats? I'm assuming that any codepage sharing done by the VM would=0A= >> be based on the absolute path to the JAR, and hence in an OSGi model=0A= >> where we have a bundle cache per-process, the codepages may not end=0A= >> up shared?=0A= >=0A= > I thought they only memory mapped the JRE classes, not application=0A= > classes...=0A= >=0A= That could be what I'm thinking of!=0A= =0A= Be interesting to know if they do go beyond that=0A= =0A= > -> richard=0A= >=0A= >>=0A= >>=0A= >> Feel free to respond with links to article I need to go read!=0A= >>=0A= >> -- Rob=0A= >>=0A= >>=0A= >> Ascert - Taking systems to the edge=0A= >> robw@ascert.com=0A= >> SA +27 21 300 2028=0A= >> UK +44 20 7488 3470 ext 5119=0A= >> www.ascert.com=0A= >>=0A= >=0A= =0A= --=0A= =0A= =0A= Ascert - Taking systems to the edge=0A= robw@ascert.com=0A= SA +27 21 300 2028=0A= UK +44 20 7488 3470 ext 5119=0A= www.ascert.com=0A= =0A=