Skip to content

Commit

Permalink
Initial commit, from the old CVS repository.
Browse files Browse the repository at this point in the history
  • Loading branch information
AdamSpitz committed Mar 22, 2009
0 parents commit 440061b
Show file tree
Hide file tree
Showing 917 changed files with 191,730 additions and 0 deletions.
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
.DS_Store
32 changes: 32 additions & 0 deletions doc/AspectsOfKlein.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
Here's a list of various aspects of Klein that we could talk about.

----

Principles: We are following certain principles which have traditionally been difficult to adhere to when building VMs: object-orientation, metacircularity, heavy code reuse, reactivity, early unit testing, mirror-based reflection, and subjectivity.

Architecture: An overview of the anatomy of Klein, including the object system, the compiler, the export system, and the remote debugging environment.

Metacircularity: The Klein VM is written in the language that it implements (Self). This has the potential to allow us to greatly simplify the VM. The VM and the application both use the same calling convention. Garbage collection (not there yet) will use the same mechanism to find roots in application stack frames as in VM stack frames. Whereas in a C(++)-based virtual machine, an object is described by another object (a class or map), which in turn is described by a different mechanism (hard-compiled C(++) structure declarations), in a metacircular VM, an object is described by another object (the class or map), which is described by another object (the map's map), etc. This infinite recursion must be terminated by choosing to "hardwire" some facts about object layout. Many strategies are possible. We can go over what we have done so far, which we view as possibly an interim solution.

Self-testing assembler: The Klein assembler and disassembler are generated from the machine's instruction set architecture (ISA) spec. The system tests itself by automatically generating test cases, assembling and then disassembling them to make sure the result matches the original, and also by running those test cases through the Unix assembler to make sure the Klein assembler produces the same code as the Unix assembler. This system has even uncovered minor bugs in both Apple's and Sun's assemblers. The Klein assembler system has been ported to Java.

Patent: Dual-mode disassembler: We have a patent on the way the Klein disassembler can interpret an instruction as either the most specific or the most general form of that instruction.

Primitives: One of the goals of Klein is to find out whether a VM can be written with no C code at all, but it seems that a C-like layer may be emerging naturally (simply as a result of good factoring) in the part of the compiler that implements primitive operations.

Performance problems with the export cycle: Our dedication to our principles has led us to performance problems with the Klein export cycle. Consequently, Klein development seems to consist of a cycle of two distinct phases: a functionality phase, where we add new functionality to the Klein VM, until the export cycle becomes unbearably slow, at which point we go into an optimization phase.

Graphical profiling: Our frustration with the textual Self performance profiler has led us to create a graphical profiler widget. In the graphical profiler, we have the advantage of all of the Self UI's direct-manipulation facilities. The graphical profiler also includes a pruning algorithm, since most nodes in a performance profile are uninteresting.

Programming environment: We reuse the Self programming environment, which contains features some people may not be acquainted with. These include various browsing tools (e.g. cross-referencing), working in a dynamic world of live objects, a mirror-based reflection architecture, and others.

Remote debugging environment: Klein's metacircularity and Self's mirror-based reflection architecture have let us reuse a vast amount of code from the Self programming environment in order to create a Klein environment. The Klein environment allows us to view and debug a remote Klein process from a Self world, at either source- or machine- level.

Patent: Register-showing: We have a patent on the way the Klein machine-level debugger shows you the contents of only the registers mentioned by the particular machine code displayed in the debugger.

Reuse of the reflection system: We use a "lens-based" architecture to allow Klein's reflective code to function in several different contexts: as the code used to build the objects in the bootstrap image, as the code used to examine remote Klein objects in the Klein remote debugging environment, and as Klein's runtime reflection system.

Comparison to related projects: An overview of the differences between Klein and other metacircular VMs: Squeak, Squawk, Jikes, Joeq, OVM.

Demo of current functionality: Neither the Klein development environment nor the VM itself are complete yet, but they do include significant functionality. The development environment includes source-level object outliners, and a source-level and machine-level debugger, though these are missing much of the on-the-fly modification facilities of the regular Self environment. The VM itself is capable of running its own compiler to compile a very simple method.

13 changes: 13 additions & 0 deletions doc/Copyright.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
Copyright 2006 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved.

Sun Microsystems, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed at http://www.sun.com/patents and one or more additional patents or pending patent applications in the U.S. and in other countries.

U.S. Government Rights - Commercial software. Government users are subject to the Sun Microsystems, Inc. standard license agreement and applicable provisions of the FAR and its supplements.

Use is subject to license terms.

Sun, Sun Microsystems and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon architecture developed by Sun Microsystems, Inc.

This product is covered and controlled by U.S. Export Control laws and may be subject to the export or import laws in other countries. Nuclear, missile, chemical biological weapons or nuclear maritime end uses or end users, whether direct or indirect, are strictly prohibited. Export or reexport to countries subject to U.S. embargo or to entities identified on U.S. export exclusion lists, including, but not limited to, the denied persons and specially designated nationals lists is strictly prohibited.
76 changes: 76 additions & 0 deletions doc/KindsOfPrimitives.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
Here's a list of commonalities between primitives:

TT = type tests
ML = materializeLocs
ED = encode/decode smi
CS = conditional stuff
TR = tempReg
AS = arithmetic stuff
MS = magic slot
LO = load oop
ST = stub thingy
LF = location fiddling
CA = constant args
OF = overflow
BC = bounds check
LS = loading/storing

[TT, ML, ED, AS] ForBytesPart: At: IfFail:
[TT, ML, ED, CS, TR, AS] ForBytesPart: At: Put: IfFail:
[TT, ML, MS] ForBytesPart: SetIndexableSize: IfFail:
[TT, ML, MS] IndexableSizeOfBytesPart: IfFail:

[] BreakpointIfFail:
[CA] Breakpoint: IfFail:

[ML, TR, AS] LookupTypeIsNormalIfFail:
[ML, TR, AS] LookupTypeMatches: IfFail:

[ST, LF] CloneIfFail:
[ML, CS, TT] CreateObjectReferenceWithTag: AndValue: IfFail:
[ML, CS] Eq: IfFail:
[ML, TR, CA] In: WhichIsOfType: Get: IfFail:
[ML] MapIfFail:
[ML, AS] TagPartOfObjectReferenceIfFail:
[ML, AS] ValuePartOfObjectReferenceIfFail:

[ML, TT, ED] IntForCIfFail:
[ML, TR, ED, CS] IntFromCIfFail:

[ML, TT, CS, AS, OF] IntAdd: IfFail:
[ML, TT, CS, ED, AS, OF] IntDiv: IfFail:
[ML, TT, CS, ED, AS, OF] IntMul: IfFail:
[ML, TT, CS, AS, OF] IntSub: IfFail:

[ML, TT, CS, ED, AS, OF] IntArithmeticShiftLeft: IfFail:
[ML, TT, CS, ED, AS] IntArithmeticShiftRight: IfFail:

[ML, TT, CS, AS] IntEQ: IfFail:
[ML, TT, CS, AS] IntLE: IfFail:

[ML, TT, TR, AS] ForMemoryObject: At: IfFail:
[ML, TT, AS] ForMemoryObject: At: Put: IfFail:
[ML, TT, AS, CS] ForMemoryObject: IsMarkAt: IfFail:
[ML, TT, ED] ForMemoryObject: SetMarkValue: IfFail:
[ML, TT, ED] MarkValueOfMemoryObject: IfFail:

[ML, TT, TR] CloneBlockHomeFrame: IfFail:

[ML, TT, TR, MS] ByteSizeIfFail:
[ML, TT, TR, MS, AS] ByteVectorForCIfFail:

[ML, TT, TR] NMethodEntryPointIfFail:

[ML, TT, TR, AS, BC] At: IfFail:
[ML, TT, TR, MS] SizeIfFail:

[ML, TT, TR, MS] NMethodCacheIfFail:

[ML, TR, LS] BackpatchSendDescTo: IfFail:
[ML] CallingSendDescIfFail:
[] RetrySendDescIfFail:
[ML] SendDescDelegateeIfFail:
[ML] SendDescLookupTypeIfFail:
[ML] SendDescSelectorIfFail:

[ML, LO] TheVMIfFail:
Loading

0 comments on commit 440061b

Please sign in to comment.