Re: the End of History in the constant pool

[Krystal Mok]

Hi John,

Thanks for moving the conversation to mlvm-dev! The condy stuff is finally
coming, yay!

Just out of curiousity, since we're on this topic, may I ask about what
constant tags 13 and 14 used to mean?
All I could find was that 13 was used in JavaCard VM (JCVM) as
CONSTANT_Package. But what was the full story behind the missing 13 and 14
here?

Thanks,
Kris

On Thu, May 18, 2017 at 12:55 PM, John Rose  wrote:

> (I'm moving an amber-dev conversation about condy to mlvm-dev.)
>
> We are working on a condy JEP and spec. as well as a prototype, which is
> good progress.  I'll post some info about that in a moment.
>
> On May 18, 2017, at 12:16 PM, Remi Forax  wrote:
>
>
> I would prefer 17 to 21, because 21 is already used internally by ASM :)
>
>
> I don't think anyone is objecting to 17 for CONSTANT_ConstantDynamic,
> and I expect 17 is what we will land on.  It's been held open for
> (approximately)
> this purpose.
>
> Fun facts from History:  CONSTANT_17 was used by a prototype version of
> invokedynamic which was discarded.  (The EG wisely discarded a couple of
> designs,
> including a design without method handles!)  The prototype in that case
> overloaded
> the invokeinterface instruction, in ways which are useless to recall.  In
> order to make
> a clean break, we helped ourselves to another constant tag.  Soon after
> that,
> I realized a future need for expression-like structures threaded through
> the constant
> pool and bootstrap specifiers, although it was a bridge too far at the
> time.  So
> we made no effort to "compact" our constant pool tag usage, knowing there
> might
> be followup work in the future.
>
> Also:  From the primordial days of Java there is CONSTANT_Unicode (tag 2)
> which AFAIK has never been used from JDK 1 forward.  I think modern "take"
> on
> character sets is to have one format for text (usually UTF8) and one for
> binary
> octets.  (This is exemplified, for example, in CBOR.)  I expect some day
> to use
> the constant tag 2 for such a purpose.  Basically, it would amount to
> giving class
> files the power to "swallow" resource files (or smaller random byte
> snippets).
> It has an obvious multiplicative effect on condy, but we don't need it
> yet, so
> we are going with the minimal proposal.
>
> I think the Ultimate, End-of-History CP tags are CONSTANT_ConstantDynamic,
> CONSTANT_Data, and CONSTANT_Group.
>
> The Group is simply a subsequence of CP values (probably of limited set of
> types).
> It would be used for packing array constants and other aggregate types.
> Today we use bootstrap specifiers, which can be as long as 2^16-1 items,
> so there's no immediate motivation for a new grouping construct.  But the
> main point
> of a Group would be to lift the restriction that all CP constants are
> defined in one
> space of 2^16-1 code points.  Instead, a group would contain serialized CP
> entries that have no absolute CP index, but rather are loaded as part of
> the group.
>
> The group's size limit could also be raised to a u4 from u2.  I think the
> octet data
> size limit should be u8 but that requires further API work in the JDK.  My
> hope is that
> both Data and Group can serve at a wide range of length scales, O(10) to
> O(10^10).
>
> In the interests of incremental delivery, the forthcoming JEP only deals
> with a limited
> subset of this stuff.   The bug JDK-8161256 is a "kitchen sink"
> description of proposals
> (both live and abandoned) for futures in this direction.
>
> — John
>
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Threaded interpreter in Java

[Krystal Mok]

Thanks Rémi!

On Thu, Aug 4, 2016 at 5:36 PM, Remi Forax <fo...@univ-mlv.fr> wrote:

> Hi Krys,
>
>
> On August 3, 2016 3:41:46 PM PDT, Krystal Mok <rednaxel...@gmail.com>
> wrote:
> >(Having missed last night's dinner and all the fun there...)
> >
> >When Rémi started talking about this interpreter today, I thought it'd
> >be
> >tailcall related.
>
> I would love that it was tailcall related too. people seams to reduce
> tailcall to a feature of some obscure languages but in reality each time
> you have to do some argument transformations/injections/checking in a
> generic way, it screams for tailcall.
>
> >
> >In college, my introductory course to computer systems was based on the
> >book "Introduction to Computing Systems: From Bits & Gates to C &
> >Beyond",
> >where it introduces a small educational 16-bit architecture called
> >LC-2. We
> >were given a LC-2 simulator to run our "assembly" programs.
> >Later on, when I've learned enough Java to be dangerous, I wanted to
> >write
> >a more powerful simulator (interpreter) of the LC-2 ISA in Java.
> >
> >My first version was a most straightforward switch-threaded one.
> >Nothing
> >much to be said about that.
> >
> >The next version, wanting to mimic a indirect-threaded style, was
> >structured in very much the same way Rémi presented in the link, but
> >MethodHandle was still years from available so I didn't have the luxury
> >of
> >using it. Instead, I modeled the opcode handlers as "single-method
> >objects", and do a virtual call at the end of each handler.
> >(So, instead of Rémi's MH calls, I'm just using a table lookup +
> >virtual
> >call)
> >
> >public class NopHandler extends AbstractHandler // or implements
> >Handler
> >{
> >  public void execute(State s) {
> >HANDLERS[s.code[s.pc++]].execute(s); // dispatch
> >  }
> >}
> >
> >That's didn't work out quite well. The performance was okay-ish with
> >small
> >program inputs. But HotSpot's JIT compilers doesn't implement tail call
> >optimizations (well, recursive inlining sort of counts...), so with a
> >long-enough program the stack blows up. And it didn't take that long of
> >a
> >LC-2 assembler program to make it blow up.
> >
>
> To avoid of blowing the stack, the trick is to stop the "trace" at the end
> of a basic block, i.e. when you have a jump or a return. It also means that
> things like null check, things that should not jump, has to be encoded with
> a different bytecode that conditional jump because you don't want to stop
> the trace for them.
>
> Cool! I haven't thought about using this trick in the context of an
interpreter in Java. That's really neat!


> >Need a good trampoline. Need proper tail calls.
>
> YES !
>
> YES!!

Thanks,
Kris


> >
> >- Kris
>
> Rémi
>
> >
> >On Wed, Aug 3, 2016 at 3:14 PM, John Rose <john.r.r...@oracle.com>
> >wrote:
> >
> >> On Aug 3, 2016, at 1:22 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
> >> >
> >> > Charles ask if we can make a fast register interpreter in Java,
> >> > here is my take on a threaded-like interpreter
> >> >
> >> > https://gist.github.com/forax/f38b533e089217cfc4d0ae3c6e2de9c9
> >>
> >> Nicely done.  We were talking last night at dinner about making
> >> bytecode interpreters go fast, and this is helpful.
> >>
> >> I think there may be a combinator here, for bytecode dispatch loops.
> >> (This feels like the PIC combinator, both fundamental and tricky to
> >get
> >> right.)
> >> A "bytecode" dispatch combinator might provide a pattern like the
> >> following:
> >>
> >> MethodHandle init, pred, step, fini, index;
> >> @NonNull MethodHandle[] tab;
> >> R dispatch(A… a) {
> >>V v = init(a…);  // one here; there might be many v…
> >>while (pred(a…)) {
> >>   v = step(v, a…);
> >>   // execute one "instruction":
> >>   int i = index(v, a…);
> >>   tab[i].invokeExact(v, a…);
> >>}
> >>return fini(V, a…);
> >> }
> >>
> >> The explicit table would be recopied internally to an @Stable array
> >for
> >> constant folding.
> >> The various index values could be tracked and turned into traces (or
> >some
> >> other profile
> >> driven structure) which would be compiled together, in specialize

Re: Threaded interpreter in Java

[Krystal Mok]

(Having missed last night's dinner and all the fun there...)

When Rémi started talking about this interpreter today, I thought it'd be
tailcall related.

In college, my introductory course to computer systems was based on the
book "Introduction to Computing Systems: From Bits & Gates to C & Beyond",
where it introduces a small educational 16-bit architecture called LC-2. We
were given a LC-2 simulator to run our "assembly" programs.
Later on, when I've learned enough Java to be dangerous, I wanted to write
a more powerful simulator (interpreter) of the LC-2 ISA in Java.

My first version was a most straightforward switch-threaded one. Nothing
much to be said about that.

The next version, wanting to mimic a indirect-threaded style, was
structured in very much the same way Rémi presented in the link, but
MethodHandle was still years from available so I didn't have the luxury of
using it. Instead, I modeled the opcode handlers as "single-method
objects", and do a virtual call at the end of each handler.
(So, instead of Rémi's MH calls, I'm just using a table lookup + virtual
call)

public class NopHandler extends AbstractHandler // or implements Handler
{
  public void execute(State s) {
HANDLERS[s.code[s.pc++]].execute(s); // dispatch
  }
}

That's didn't work out quite well. The performance was okay-ish with small
program inputs. But HotSpot's JIT compilers doesn't implement tail call
optimizations (well, recursive inlining sort of counts...), so with a
long-enough program the stack blows up. And it didn't take that long of a
LC-2 assembler program to make it blow up.

I realized that I had to have proper tail calls to make it work. So I added
a central dispatch loop to serve as a trampoline, e.g.

Handler next = getNextHandler();
while (next != null) {
  next = next.execute(s);
}

where my Handler.execute() would still perform the lookup, but not the
actual invocation. As expected, the performance was no where as good as
directly making the virtual call at the tail position in each handler. This
central dispatch loop makes the unpredictable-ness of the Handler.execute()
significant.

Need a good trampoline. Need proper tail calls.

- Kris

On Wed, Aug 3, 2016 at 3:14 PM, John Rose  wrote:

> On Aug 3, 2016, at 1:22 PM, Remi Forax  wrote:
> >
> > Charles ask if we can make a fast register interpreter in Java,
> > here is my take on a threaded-like interpreter
> >
> > https://gist.github.com/forax/f38b533e089217cfc4d0ae3c6e2de9c9
>
> Nicely done.  We were talking last night at dinner about making
> bytecode interpreters go fast, and this is helpful.
>
> I think there may be a combinator here, for bytecode dispatch loops.
> (This feels like the PIC combinator, both fundamental and tricky to get
> right.)
> A "bytecode" dispatch combinator might provide a pattern like the
> following:
>
> MethodHandle init, pred, step, fini, index;
> @NonNull MethodHandle[] tab;
> R dispatch(A… a) {
>V v = init(a…);  // one here; there might be many v…
>while (pred(a…)) {
>   v = step(v, a…);
>   // execute one "instruction":
>   int i = index(v, a…);
>   tab[i].invokeExact(v, a…);
>}
>return fini(V, a…);
> }
>
> The explicit table would be recopied internally to an @Stable array for
> constant folding.
> The various index values could be tracked and turned into traces (or some
> other profile
> driven structure) which would be compiled together, in specialized
> segments of the unrolled
> interpreter loop.
>
> Or maybe just the table lookup part alone makes a good combinator, to be
> paired
> with the loop combinators?
>
> Comments welcome…
>
> — John
>
> P.S. Another new RFE:
> experimental hook for creating heisenboxes
> https://bugs.openjdk.java.net/browse/JDK-8163133
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Coroutine

[Krystal Mok]

Hi,

The coroutine patch you would find in OpenJDK MLVM project is from Lukas
Stadler.
The project page is here: http://ssw.jku.at/General/Staff/LS/coro/
You should be able to find answers to your questions on the project page.

- Kris

On Mon, Jun 1, 2015 at 2:37 AM, lee json jsonlee...@gmail.com wrote:

 Sorry for such naive question, but I can't find any explanation or
 document about this through googling mailing list, etc. Have openjdk
 already support coroutine? If so, which version? Or which version may
 support this feature?

 Thanks
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: TaggedArrays (Proposal)

[Krystal Mok]

On Tue, Jul 3, 2012 at 1:28 PM, Howard Lovatt howard.lov...@gmail.comwrote:

 I like the idea and something along these lines would be a great addition
 to the standard library, which I will come back to as a PS.

 In com.sun.misc.Unsafe there are already getLong(Object, int) and
 setLong(Object, int, long) methods and the same for Object. No doubt if we
 used getLong and setLong as they stand they would fail due to type checking
 if used to access references to Objects in an Object[]. However if similar
 methods were added that circumvented the type checking,
 getLongOrReference(Object, int) and setLongOrReference(Object, int, long),
 then you could write:

 private Object[] vsAndRs;

 ...

 @Override public long getValue(final int index) {
 checkIndex(pos);
 final long value = Unsafe.getLongOrReference(vsAndRs, index);
 if ( (value  TaggedArrays.TAG) != 0 ) {
 return value;
 }
 throw new TaggedArrayException(value at index = + index +  is not
 tagged);
 }

 @Override public Object getReference(final int index) {
 if ( isReference(index) ) {
 return vsAndRs[index];
 }
 throw new TaggedArrayException(reference at index = + index + is
 tagged);
 }

 ..

 Which would save half the space and still be understandable Java (i.e. not
 a collection of native calls).

 It's not just about type checking at Java level, but also something deep
within the VM: the need to distinguish between a plain value and a
reference (pointer), which is fundamental to a exact/accurate garbage
collector.
Jim's idea includes modifying the doOop() function in the VM, which is
exactly where HotSpot handles reference fields within an object.

If you put random values into a place where HotSpot (or other JVM impls
using exact GC) think it's a reference, then something bad may happen later
(e.g. during GC), that the VM think it had found a corrupted reference.

- Kris


 Great work,

  -- Howard.

 PS A few random thoughts for the interface, assuming that something like
 this makes it into the JDK then the following additions might be nice:

 1. Fills that accept a lambda that receives the index as its argument
 (filling function as opposed to filling constant).
 2. A second interface and second factory that define tagged arrays for
 long and double in addition to Objects, like the example code given.
 3. TaggedArray32, primarily for phones etc., with the extended interface,
 point 2 above, for TaggedArray32 accepting Objects, ints, and floats. On a
 64 bit system TaggedArray32 would be the same as TaggedArray, but for 32
 bit systems it would save space.


 On 2 July 2012 23:05, Jim Laskey jlas...@me.com wrote:

 During a week in the rarefied air of Stockholm back in May, a sleepless
 night got me thinking.  The day after that, the thinking became a reality.
  I've been sitting on the code since, not sure what to do next.  So..., why
 not start the month leading up to the JVMLS with a discussion about dynamic
 values.

 Every jLanguage developer knows that primitive boxing is the enemy.  Even
 more so for untyped languages.  We need a way to interleave primitive types
 with references.

 Tagged values (value types) for dynamic languages have been approached
 from a dozen different angles over the history of Java.  However, no one
 seems to be satisfied with any of the proposals so far.  Either the
 implementation is too limiting for the language developer or too complex to
 implement.

 Most recently, John (Rose) proposed hiding value tagging in the JVM via
 the Integer/Long/Float/Double.valueof methods.  I saw a few issues with
 this proposal.  First, the implementation works differently on 32 bit and
 64 bit platforms (only half a solution on each).  Secondly, control of the
 tag bits is hidden such that it doesn't give a language implementor any
 leeway on bit usage.  Finally, it will take a long time for it to get
 introduced into the JVM.  The implementation is complex, scattered all over
 the VM and will lead to a significant multiplier for testing coverage.

 It occurred to me on that sleepless Monday night, that the solution for
 most dynamic languages could be so much simpler.  First, we have to look at
 what it is we really need.  Ultimately it's about boxing.  We want to avoid
 allocating memory whenever we need to store a primitive value in an object.
  Concerning ourselves with passing around tagged values in registers and
 storing in stack frames is all red herring.  All that is needed is a
 mechanism for storing tagged values (or compressed values) in a no-type
 slot of a generic object.  Thinking about it in these terms isolates all
 issues to a single array-like class, and thus simplifies implementation and
 simplifies testing.  Instances of this class can be used as objects, as
 stack frames and even full stacks.  A good percentage of a dynamic language
 needs are covered.

 So, Rickard Bäckman (also of Oracle) and I defined an API and implemented
 (in HotSpot) an 

Re: TaggedArrays (Proposal)

[Krystal Mok]

@Howard

Your suggestion could pretty much work if the underlying VM is using a
conservative collector, where it'd actually include a set of filters to
check if a value is a (or looks like a) real reference.

There are also a couple of runtimes that implements exact GC by tagging
values, but most JVMs that I know of doesn't work that way. They'd expect
all reference type fields to contain valid references.

- Kris

On Tue, Jul 3, 2012 at 1:46 PM, Howard Lovatt howard.lov...@gmail.comwrote:

 @Kris, I was assuming that the tag would be sufficient for the JVM since
 'real' references would be aligned and hence naturally not tagged. But I
 don't know enough about the JVM and hence you could well be correct. --
 Howard.


 On 3 July 2012 15:40, Krystal Mok rednaxel...@gmail.com wrote:

 On Tue, Jul 3, 2012 at 1:28 PM, Howard Lovatt howard.lov...@gmail.comwrote:

 I like the idea and something along these lines would be a great
 addition to the standard library, which I will come back to as a PS.

 In com.sun.misc.Unsafe there are already getLong(Object, int) and
 setLong(Object, int, long) methods and the same for Object. No doubt if we
 used getLong and setLong as they stand they would fail due to type checking
 if used to access references to Objects in an Object[]. However if similar
 methods were added that circumvented the type checking,
 getLongOrReference(Object, int) and setLongOrReference(Object, int, long),
 then you could write:

 private Object[] vsAndRs;

 ...

 @Override public long getValue(final int index) {
 checkIndex(pos);
 final long value = Unsafe.getLongOrReference(vsAndRs, index);
 if ( (value  TaggedArrays.TAG) != 0 ) {
 return value;
 }
 throw new TaggedArrayException(value at index = + index +  is not
 tagged);
 }

 @Override public Object getReference(final int index) {
 if ( isReference(index) ) {
 return vsAndRs[index];
 }
 throw new TaggedArrayException(reference at index = + index + is
 tagged);
 }

 ..

 Which would save half the space and still be understandable Java (i.e.
 not a collection of native calls).

 It's not just about type checking at Java level, but also something deep
 within the VM: the need to distinguish between a plain value and a
 reference (pointer), which is fundamental to a exact/accurate garbage
 collector.
 Jim's idea includes modifying the doOop() function in the VM, which is
 exactly where HotSpot handles reference fields within an object.

 If you put random values into a place where HotSpot (or other JVM impls
 using exact GC) think it's a reference, then something bad may happen later
 (e.g. during GC), that the VM think it had found a corrupted reference.

 - Kris


 Great work,

  -- Howard.

 PS A few random thoughts for the interface, assuming that something like
 this makes it into the JDK then the following additions might be nice:

 1. Fills that accept a lambda that receives the index as its argument
 (filling function as opposed to filling constant).
 2. A second interface and second factory that define tagged arrays for
 long and double in addition to Objects, like the example code given.
 3. TaggedArray32, primarily for phones etc., with the extended
 interface, point 2 above, for TaggedArray32 accepting Objects, ints, and
 floats. On a 64 bit system TaggedArray32 would be the same as TaggedArray,
 but for 32 bit systems it would save space.


 On 2 July 2012 23:05, Jim Laskey jlas...@me.com wrote:

 During a week in the rarefied air of Stockholm back in May, a sleepless
 night got me thinking.  The day after that, the thinking became a reality.
  I've been sitting on the code since, not sure what to do next.  So..., why
 not start the month leading up to the JVMLS with a discussion about dynamic
 values.

 Every jLanguage developer knows that primitive boxing is the enemy.
  Even more so for untyped languages.  We need a way to interleave primitive
 types with references.

 Tagged values (value types) for dynamic languages have been approached
 from a dozen different angles over the history of Java.  However, no one
 seems to be satisfied with any of the proposals so far.  Either the
 implementation is too limiting for the language developer or too complex to
 implement.

 Most recently, John (Rose) proposed hiding value tagging in the JVM via
 the Integer/Long/Float/Double.valueof methods.  I saw a few issues with
 this proposal.  First, the implementation works differently on 32 bit and
 64 bit platforms (only half a solution on each).  Secondly, control of the
 tag bits is hidden such that it doesn't give a language implementor any
 leeway on bit usage.  Finally, it will take a long time for it to get
 introduced into the JVM.  The implementation is complex, scattered all over
 the VM and will lead to a significant multiplier for testing coverage.

 It occurred to me on that sleepless Monday night, that the solution for
 most dynamic languages could be so much simpler.  First, we have

Re: OpenJDK 8 on OS/X and XCode 4.

[Krystal Mok]

Hi Mark,

PrintOptoAssembly (for C2, and PrintLIR for C1) only works in a debug build
(which fastdebug is one), where as PrintAssembly works in all builds. If
you need more annotated asm listing then you might want PrintOptoAssembly,
but if you're just after the code instead of the comments then
PrintAssembly should be good enough.

fastdebug is indeed slower (by a little; it'll vary depending on the VM
args, some args are very expensive), on startup and to run.

Regards,
Kris Mok

On Mon, Nov 7, 2011 at 4:51 PM, Mark Roos mr...@roos.com wrote:

 From Henri


 So, I could disable fastdebug in build ?

 To charles
 Do we need the fastdebug to get the asm listing? And is it slower
 to run or just start up?
 It seems to run my benchmarks about 30% slower.

 Since we have Stephen's with fast debug Henri's could be whatever gives
 the most impressive
 user experience.  I have been bouncing around three as it is anyway.

 thanks again for the work Henri
 mark
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Trying to implement fixnums

[Krystal Mok]

Hi Stepan,

Just as a sidenote, implementing Fixnums in HotSpot feels almost like
reviving the real oops that was in Strongtalk [1].

For HotSpot internals, the wiki [2] should be a good starting point.

As for the server compiler, you'd need to read a few papers to get up to
speed. [3] is the first to read.

Regards,
Kris Mok

[1]: http://www.strongtalk.org/
[2]: http://wikis.sun.com/display/HotSpotInternals/Home
[3]: http://www.usenix.org/events/jvm01/full_papers/paleczny/paleczny.pdf

On Tue, Oct 25, 2011 at 7:31 AM, Stepan Koltsov y...@mx1.ru wrote:

 Hi,

 I'm trying to implement fixnums (
 http://blogs.oracle.com/jrose/entry/fixnums_in_the_vm ).

 Task seems to be relatively easy. However, I don't know OpenJDK
 internals at all, so I'm asking for your help.

 First thing I'm trying to do is to override Integer.valueOf on 64-bit JVM.

 So, Integer.valueOf is already an intrinsic.

 I created class MakeIntFixnumNode extends Node, and I added code to
 library_call.cpp that converts Integer.valueOf call to
 MakeIntFixnumNode.

 And that's all. I stuck :)

 Have any suggestions? Am I moving in the right direction? Which parts
 of code should I patch?

 Another question: are there any documents, blogs, articles describing
 hotspot internals?

 --
 Stepan
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Google Dart

[Krystal Mok]

Rhino is getting a renewal https://github.com/mozilla/rhino
dyn.js is another project that implements JavaScript in Java 7. You might be
interested in that as well: http://www.infoq.com/news/2011/10/dynjs

On Mon, Oct 10, 2011 at 9:56 PM, Alexander Turner 
nerdscent...@googlemail.com wrote:

 So rhino has been update for java 7? Wow I must take a look.
 On Oct 10, 2011 1:17 PM, Rémi Forax fo...@univ-mlv.fr wrote:

  In fact, there is already a frontend in Java:

 http://code.google.com/p/dart/source/browse/#svn%2Fbranches%2Fbleeding_edge%2Fdart%2Fcompiler%2Fjava%2Fcom%2Fgoogle%2Fdart%2Fcompiler

 It's used to compile to javascript but it can be adapted to generate
 bytecode at runtime.
 So yes, it seems simple (or not that hard) to write a runtime using
 invokedynamic.

 BTW, you can currently use Rhino for that.

 Rémi

 On 10/10/2011 10:14 AM, Alexander Turner wrote:

 It is a very interesting idea. It take Java to js trechnology google
 created and uses it for a more flexible language. The mix of static and
 dynamic typing (much like vb does/did) has a proven track record of being
 much liked by day job programmers.

 I suspect, much more than Go, this language could shake things up.

 I also anoreason itshould not run very well on the jvm under invoke
 dynamic semantics.

 For the first time in a long time - a new language to get exciterd
 about...
 On Oct 10, 2011 8:02 AM, Rémi Forax fo...@univ-mlv.fr wrote:

 On 10/10/2011 09:51 AM, Marcus Lagergren wrote:
  FYI,
 
  Google Dart now has a twitter account :
  https://twitter.com/#!/dart_lang
  https://twitter.com/#%21/dart_lang and Website is up
  http://www.dartlang.org/
 
  /M

 OMG, Dart is the next Java not the next Javascript !

 Rémi

 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



 ___
 mlvm-dev mailing 
 listmlvm-...@openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Google Dart

[Krystal Mok]

It's cute when you can find DartEntry::InvokeDynamic(...) in Dart VM's code
[1] :-)
(Just for fun; doesn't imply any connection with JVM's invokedynamic)

[1]:
http://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/runtime/vm/code_generator.cc#619

-- Kris

On Tue, Oct 11, 2011 at 3:06 AM, Attila Szegedi szege...@gmail.com wrote:

 Yup, seems like it's very easy to implement on top of the JVM with
 invokedynamic. it's actually almost uncannily suitable for just that…

 On Oct 10, 2011, at 11:58 AM, Charles Oliver Nutter wrote:

  I agree it would be an interesting language on the JVM. It may be the
  dynamic Java I've wanted to make for a long time, with the added
  bonus of optional static types.
 
  This could almost be a weekend project atop invokedynamic.
 
  - Charlie
 
  On Mon, Oct 10, 2011 at 1:14 AM, Alexander Turner
  nerdscent...@googlemail.com wrote:
  It is a very interesting idea. It take Java to js trechnology google
 created
  and uses it for a more flexible language. The mix of static and dynamic
  typing (much like vb does/did) has a proven track record of being much
 liked
  by day job programmers.
 
  I suspect, much more than Go, this language could shake things up.
 
  I also anoreason itshould not run very well on the jvm under invoke
 dynamic
  semantics.
 
  For the first time in a long time - a new language to get exciterd
 about...
 
  On Oct 10, 2011 8:02 AM, Rémi Forax fo...@univ-mlv.fr wrote:
 
  On 10/10/2011 09:51 AM, Marcus Lagergren wrote:
  FYI,
 
  Google Dart now has a twitter account :
  https://twitter.com/#!/dart_lang
  https://twitter.com/#%21/dart_lang and Website is up
  http://www.dartlang.org/
 
  /M
 
  OMG, Dart is the next Java not the next Javascript !
 
  Rémi
 
  ___
  mlvm-dev mailing list
  mlvm-dev@openjdk.java.net
  http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
  ___
  mlvm-dev mailing list
  mlvm-dev@openjdk.java.net
  http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 
  ___
  mlvm-dev mailing list
  mlvm-dev@openjdk.java.net
  http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Help with JIT talk for tomorrow

[Krystal Mok]

On Mon, Oct 10, 2011 at 3:43 AM, Sebastian Sickelmann 
sebastian.sickelm...@gmx.de wrote:

 Unfortunately http://wikis.sun.com/display/HotSpotInternals/Home seems to
 be down.

 :-(

 Same here. I was trying to access it last night and I got redirected to Bug
Database instead.


 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Help with JIT talk for tomorrow

[Krystal Mok]

I tried to document PrintCompilation a while ago, here: 
https://gist.github.com/1165804#file_notes.md
Hope it helps. Sorry for the late reply, we're in holiday this week here in 
China.

Regards,
Kris Mok

On 2011-10-5, at 7:47, Charles Oliver Nutter head...@headius.com wrote:

 Hey all...I'm updating and expanding my talk on C2 and will be posting
 some questions. Hopefully there's someone out there who can answer
 them :)
 
 First up... given this output from PrintCompilation, what do the !
 and n and % mean?
 
 Also, in Java 7 there's now two numbers instead of one at the begining
 of the line...what are they?
 
   1401   70 java.util.concurrent.ConcurrentHashMap::hash (49 
 bytes)
   1412   71 java.lang.String::indexOf (7 bytes)
   1420   72   ! java.io.BufferedReader::readLine (304 bytes)
   1420   73 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543 bytes)
   1422   42 java.util.zip.ZipCoder::getBytes (192 bytes)
 made not entrant
   1435   74 n   java.lang.Object::hashCode (0 bytes)
   1443   29   ! sun.misc.URLClassPath$JarLoader::getResource
 (91 bytes)   made zombie
   1443   25 sun.misc.URLClassPath::getResource (74 bytes)
  made zombie
   1443   36 sun.misc.URLClassPath::getResource (74 bytes)
  made not entrant
   1443   43 java.util.zip.ZipCoder::encoder (35 bytes)
 made not entrant
   1449   75 java.lang.String::endsWith (15 bytes)
   16311 %   sun.misc.URLClassPath::getResource @ 39 (74 bytes)
   1665   76 java.lang.ClassLoader::checkName (43 bytes)
 
 - Charlie
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Help with JIT talk for tomorrow

[Krystal Mok]

Hi Rémi,

I asked if or how it could be integrated into the wiki a while ago, too,
here:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-August/004376.html
Unfortunately I haven't found a definitive answer to that question yet.

Regards,
Kris Mok

On Thu, Oct 6, 2011 at 9:59 PM, Rémi Forax fo...@univ-mlv.fr wrote:

 On 10/06/2011 03:27 PM, Krystal Mok wrote:
  I tried to document PrintCompilation a while ago, here:
 https://gist.github.com/1165804#file_notes.md
  Hope it helps. Sorry for the late reply, we're in holiday this week here
 in China.
 
  Regards,
  Kris Mok

 Wow ! Impressive !

 You should update the Hotspot internal wiki
 http://wikis.sun.com/display/HotSpotInternals/Home

 John, is it possible ?

 Rémi

 
  On 2011-10-5, at 7:47, Charles Oliver Nutterhead...@headius.com
  wrote:
 
  Hey all...I'm updating and expanding my talk on C2 and will be posting
  some questions. Hopefully there's someone out there who can answer
  them :)
 
  First up... given this output from PrintCompilation, what do the !
  and n and % mean?
 
  Also, in Java 7 there's now two numbers instead of one at the begining
  of the line...what are they?
 
 1401   70 java.util.concurrent.ConcurrentHashMap::hash
 (49 bytes)
 1412   71 java.lang.String::indexOf (7 bytes)
 1420   72   ! java.io.BufferedReader::readLine (304 bytes)
 1420   73 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543
 bytes)
 1422   42 java.util.zip.ZipCoder::getBytes (192 bytes)
  made not entrant
 1435   74 n   java.lang.Object::hashCode (0 bytes)
 1443   29   ! sun.misc.URLClassPath$JarLoader::getResource
  (91 bytes)   made zombie
 1443   25 sun.misc.URLClassPath::getResource (74 bytes)
made zombie
 1443   36 sun.misc.URLClassPath::getResource (74 bytes)
made not entrant
 1443   43 java.util.zip.ZipCoder::encoder (35 bytes)
  made not entrant
 1449   75 java.lang.String::endsWith (15 bytes)
 16311 %   sun.misc.URLClassPath::getResource @ 39 (74
 bytes)
 1665   76 java.lang.ClassLoader::checkName (43 bytes)
 
  - Charlie
  ___
  mlvm-dev mailing list
  mlvm-dev@openjdk.java.net
  http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
  ___
  mlvm-dev mailing list
  mlvm-dev@openjdk.java.net
  http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Help with JIT talk for tomorrow

[Krystal Mok]

Thank you, John ^_^

It looks like I've registered a Sun Online Account before with this email
address (rednaxel...@gmail.com), and the screen name is the same as the
email address. Didn't see how I could create an account without having the
two being the same, though. I wonder if I'll be getting a lot of spam to
this address once I really start using the account...

Regards,
Kris Mok

On Fri, Oct 7, 2011 at 1:19 AM, John Rose john.r.r...@oracle.com wrote:

 Sadly, wikis.sun.com is infested by comment spammers.  Adding actual page
 edit rights is a human-intensive operation.

 Kris, what's your login (screen name) on wikis.sun.com?  I will try to add
 you to the editors list for those pages.

 -- John

 On Oct 6, 2011, at 7:11 AM, Krystal Mok wrote:

 Hi Rémi,

 I asked if or how it could be integrated into the wiki a while ago, too,
 here:
 http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-August/004376.html
 Unfortunately I haven't found a definitive answer to that question yet.

 Regards,
 Kris Mok

 On Thu, Oct 6, 2011 at 9:59 PM, Rémi Forax fo...@univ-mlv.fr wrote:

 On 10/06/2011 03:27 PM, Krystal Mok wrote:
  I tried to document PrintCompilation a while ago, here:
 https://gist.github.com/1165804#file_notes.md
  Hope it helps. Sorry for the late reply, we're in holiday this week here
 in China.
 
  Regards,
  Kris Mok

 Wow ! Impressive !

 You should update the Hotspot internal wiki
 http://wikis.sun.com/display/HotSpotInternals/Home

 John, is it possible ?

 Rémi

 
  On 2011-10-5, at 7:47, Charles Oliver Nutterhead...@headius.com
  wrote:
 
  Hey all...I'm updating and expanding my talk on C2 and will be posting
  some questions. Hopefully there's someone out there who can answer
  them :)
 
  First up... given this output from PrintCompilation, what do the !
  and n and % mean?
 
  Also, in Java 7 there's now two numbers instead of one at the begining
  of the line...what are they?
 
 1401   70 java.util.concurrent.ConcurrentHashMap::hash
 (49 bytes)
 1412   71 java.lang.String::indexOf (7 bytes)
 1420   72   ! java.io.BufferedReader::readLine (304 bytes)
 1420   73 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543
 bytes)
 1422   42 java.util.zip.ZipCoder::getBytes (192 bytes)
  made not entrant
 1435   74 n   java.lang.Object::hashCode (0 bytes)
 1443   29   ! sun.misc.URLClassPath$JarLoader::getResource
  (91 bytes)   made zombie
 1443   25 sun.misc.URLClassPath::getResource (74 bytes)
made zombie
 1443   36 sun.misc.URLClassPath::getResource (74 bytes)
made not entrant
 1443   43 java.util.zip.ZipCoder::encoder (35 bytes)
  made not entrant
 1449   75 java.lang.String::endsWith (15 bytes)
 16311 %   sun.misc.URLClassPath::getResource @ 39 (74
 bytes)
 1665   76 java.lang.ClassLoader::checkName (43 bytes)
 
  - Charlie
  ___
  mlvm-dev mailing list
  mlvm-dev@openjdk.java.net
  http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
  ___
  mlvm-dev mailing list
  mlvm-dev@openjdk.java.net
  http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

[Krystal Mok]

Hi John,

On Tue, Sep 20, 2011 at 5:58 AM, John Rose john.r.r...@oracle.com wrote:

 The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by
 looking at the behavior of artificial workloads.  Experience with real
 workloads will probably lead to further modifications (under new Change
 Requests).  I thought of making them tunable from JVM command line
 properties, but since no other class in java.lang does this, I held back.


FYI, There's one, java.lang.Integer's cache size is tunable via JVM command
line flag -XX:AutoBoxCacheMax, which in turn sets Java system property
java.lang.Integer.IntegerCache.high, and affects the Integer cache size.
But that's probably a special case anyway.

Regards,
Kris Mok
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev