Re: JIT pluggability (ABI Issues)

2004-01-13 Thread Patrik Reali
Hi!

What I meant was the order parameters are pushed on the stack. Please 
excuse my previous underspecified statement.

As a side node, pushing parameters right-to-left makes the implementation 
of open parameter lists much simpler (maybe this is another reason C tends 
to use it?).

-Patrik



--On Montag, 12. Januar 2004 12:59 -0800 Per Bothner [EMAIL PROTECTED] 
wrote:

Patrik Reali wrote:

Calling Convention
* left-to-right (as in java) or right-to-left (as in C)
Huh?  Argument evaluation order is not really part of the ABI.
C has *unspecified* evaluation order, so many implementations
have evaluated them right-to-left because that's the way the
stack grows (on most C implementations).  But this is less
relevant with optimizing compilers and register-based calling
conventions.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath


Re: [patch #2388] DefaultTableCellRenderer update

2004-01-13 Thread Arnaud Vandyck
Michael Koch [EMAIL PROTECTED] writes:

 /**/
 [patch #2388] Latest Modifications:

 Changes by: 
   Michael Koch [EMAIL PROTECTED]
 'Date: 
   Mon 01/12/04 at 20:21 (GMT)

 What | Removed   | Added
 ---
   Status | Open  | Closed


 -- Additional Follow-up Comments 
 I commited a sligtly edited patch to CVS.

Very kind, thank you! ;)

I'm a litttle busy at the moment but I'll try to rework on other parts
of Swing as soon as I can.

Cheers,

-- 
Arnaud Vandyck, STE fi, ULg
Formateur Cellule Programmation.


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath


Re: JIT pluggability (ABI Issues)

2004-01-13 Thread Chris Gray
On Monday 12 January 2004 21:28, Patrik Reali wrote:
 * class layout (do we really need this? I guess the fields are allocated in
 the row as they are declared)

Some VMs may group all reference fields together, or try to pack fields 
smaller than 16 bits (boolean, byte, short, char).

-- 
Chris Gray  /k/ Embedded Java Solutions
Embedded  Mobile Java, OSGi  http://www.kiffer.be/k/
[EMAIL PROTECTED]  +32 477 599 703


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath


Re: JIT pluggability (ABI Issues)

2004-01-13 Thread shudo
From: Chris Gray [EMAIL PROTECTED]

 On Monday 12 January 2004 21:28, Patrik Reali wrote:
  * class layout (do we really need this? I guess the fields are allocated in
  the row as they are declared)

 Some VMs may group all reference fields together, or try to pack fields
 smaller than 16 bits (boolean, byte, short, char).

I remember Project Monty (by Lars Bak, Sun) developed such a JVM for
CLDC profile.  The JVM became CLDC HotSpot later.

And there were several researches focusing on layout of object fields.
One of them might be based on SableVM.

  Kazuyuki Shudo[EMAIL PROTECTED]   http://www.shudo.net/


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath


Re: JIT pluggability (ABI Issues)

2004-01-13 Thread Sascha Brawer
CG = Chris Gray [EMAIL PROTECTED] wrote:
PR = Patrik Reali [EMAIL PROTECTED] wrote:

PR * class layout (do we really need this? I guess the fields are
PR allocated in the row as they are declared)

CG Some VMs may group all reference fields together, or try to
CG pack fields smaller than 16 bits (boolean, byte, short, char).

Please apologize for this kind of off-topic post, but in case anyone was
interested in the subject, please find below a few references to
background reading. There surely exist plenty more papers in this area.

--

[Chilimbi et al., 1999] Trishul M. Chilimbi, Bob Davidson, and James R.
Larus. Cache-Conscious Structure Definition. In Proceedings of the ACM
SIGPLAN Conference on Programming Language Design and Implementation
(PLDI '99), May 1999, pp. 13--24.

(a) Class Splitting separates the fields of eligible classes into a
frequently and a rarely accessed part, based on instrumentation data. The
optimization is applicable to classes whose size roughly equals a cache
block (common for Java programs), provided enough variation in field
access frequency. Because of fewer cache misses, the performance of five
Java programs has improved by 6 -- 18%. -- (b) Field Reordering could
further improve the performance of Microsoft SQL server by 3%, despite
previous cache-concious C programming. Illustrates that structure layout
is better left to the compiler.

--

[Dolby and Chien, 2000] Julian Dolby and Andrew A. Chen. An Automatic
Object Inlining Optimization and its Evaluation. In Proceedings of the
ACM SIGPLAN Conference on Programming Language Design and Implementation
(PLDI 2000), Vancouver BC, Canada, June 2000, pp. 345 - 357.

Object Inlining transforms heap data structures by fusing parent and
child objects together. It can speed up a program by reducing pointer
dereferencing and by improving memory access behavior. With the benchmark
programs, 30% of objects could be inlined, leading to 12% fewer loads,
25% fewer L1 cache misses and 25% fewer read stalls.

--

[Kistler and Franz, 2000] Thomas Kistler and Michael Franz. Automated
Data-Member Layout of Heap Objects to Improve Memory-Hierarchy
Performance. ACM Transactions on Programming Languages and Systems
(TOPLAS) 22, No. 3, May 2000. pp. 490--505.

Instrumentation data is used to build a weighted graph whose edges
represent temporal dependencies between fields. In order to assign fields
to cache lines, the graph is partitioned; a second step orders the fields
within each partition. This Field reordering improved the performance of
six Oberon programs by 3 to 50%.

--

[Shuf et al., 2001] Yefim Shuf, Mauricio J. Serrano, Manish Gupta, and
Jaswinder Pal Singh. Characterizing the Memory Behavior of Java
Workloads: A Structured View and Opportunities for Optimizations. In
Proceedings of SIGMETRICS 2001/Performance 2001, Cambridge MA, USA, June 2001.

Draws conclusions from detailed instrumentation of the SPEC JVM98 and
JBB2000 benchmark suites, running on a modified version of the JalapeƱo
VM. The L1 data cache is less effective than for C/C++ desktop workloads
(4% misses, compared to 1%). Object Inlining could partially fix the
problem caused by pointer chasing. Field re-ordering is unlikely to
increase L1-cache performance for Java, because most hot objects fit
into a 32-byte cache line. While Data Prefetching could mitigate the L1
cache situation, TLB misses are frequent as well, and current hardware
ignores prefetching instructions if the fetched address is not in the
TLB. To increase TLB hit rate, large VM pages should be used, and class
data should be co-located (because virtual method tables contribute
noticeably to TLB misses).

-- Sascha

Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath