Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: Architecture Questions - Moving to JreLite
Date: 04 Mar 2008 16:50:21 +0300
Lines: 86
Message-ID: <0vqhcfmoaxu.fsf@gmail.com>
References: <000b01c87dde$0660d480$0300000a@animal>
 <e0f125db0803040249x41d1a2fcl4d88d5d625b1fe1f@mail.gmail.com>
 <0vqpruaocvj.fsf@gmail.com>
 <e0f125db0803040536x6cc2de6bxc7cc84297c198ba7@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
Sender: news <news@ger.gmane.org>

On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> Egor,
> 
> I had an argument with JIT guys some time earlier about splitting JET
> and OPT into separate libraries. Their main argument was "shared
> code". AFAIR it was memory management, collections, and logging.

JET does not use collections, shared stuff is:

PMF, Logging, MemoryManager, microkernel, IEEE754_fmod_double, tiny
platform-dependant stuff

I believe it fits into 500K or maybe 200K :)

> Completing your idea we can move shared code into dynamic lib and use
> it dynamically from both JITs.
> 
> Pavel.
> 
> On 04 Mar 2008 16:08:32 +0300, Egor Pasko <egor.pasko@gmail.com> wrote:
> > On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> > > Johnny,
> > >
> > > see inline.
> > >
> > > On 3/4/08, Johnny Kewl <john@kewlstuff.co.za> wrote:
> > >
> > > > ICU?
> > > > (Unicode... its too big to be good)
> > > Which ICU? ICU4J is class library implementation of locales. ICU4JNI
> > > is used by DRLVM for verifying java identifiers.
> > >
> > > > Its almost perfect, the only area that naturally needs work is that the VM
> > > > does not distinguish between a user using the program and a programmer
> > > > that wants extra functionality... So Debuggers profiling tooling has to be
> > > > made all optional and dynamic links
> > > Its possible, but VM has lots of hooks inside of it related to JVMTI,
> > > and JVMTI itself is not blazingly fast. Separating into dynamic
> > > linkage won't make things faster.
> > >
> > > > Two JIT compilers ... beautiful, the OPT compiler must be optional or late
> > > > loading, its perfect, if they can be separated?
> > > In short - no. In more details, JET and OPT has lots of common
> > > functionality and separating them whould mean bigger code size.
> >
> > by lots you mean not very lots, right? :)
> >
> > the simple (and possibly incorect) solution might be to package two
> > libraries based on jitrino/src subdirectories:
> >
> > 1. jet+shared+main (jet.{so,dll})
> > 2. the rest (opt.{so,dll})
> >
> > now opt depends on jet, yey (not ery good for systems, where we do not
> > support jet, but those systems are packaged differently anyway)
> >
> > looks like rather easy and with no big increase in code size..
> >
> > > > Where are fonts actually used, not directly in the VM I hope, ie its AWT and
> > > > Swing classes, that *once loaded use them*, is that right?
> > > > Something like classloader loads up a Swing class, it draws, this is a
> > > > method call outside VM logic and links straight out to a system dll?
> > > > Where is the native side of AWT and SWING living... in harmonyvm.dll?
> > > harmonyvm.dll is the virtual machine itself. Harmony is pretty modular
> > > and does not mix dependencies (well, does not mix lots of dependencies
> > > ;)).
> > >
> > > > Thanks... Harmony is great...
> > > This is unquestionable. ;)
> > >
> > > Pavel.
> > >
> >
> > --
> > Egor Pasko
> >
> >
> 
> 
> -- 
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
> 

-- 
Egor Pasko