Jim's and Remi's comments on the problem are correct.
In the current design, MH.type values must be interned. Comments on this
design decision are interesting and useful, but this is not new ground; we went
over it during the JDK 7 engineering and spec. work. It is likely we will
revisit
On Mar 21, 2012, at 8:17 AM, Christian Thalinger wrote:
John, I think there is a bug in MacroAssembler::check_method_handle_type for
x86 (with meth-lazy):
That's correct. Thanks for noticing it; I'll push a fix. — John
___
mlvm-dev mailing list
http://cr.openjdk.java.net/~jrose/7127687/webrev.00/
7127687: MethodType leaks memory due to interning
Summary: Replace internTable with a weak-reference version.
This is a point fix for JDK 8, and will (pending approval) also be back-ported
to JDK 7u.
— John
Notes on process: This code is
http://cr.openjdk.java.net/~jrose/7087658/webrev.00/
7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that
are multiply inherited
This is a point fix for JDK 8, and will (pending approval) also be back-ported
to JDK 7u.
— John
Notes on process: This code is part of
the WeakHashMap and synchronize the accessors to
it?
Sent from my phone
On Mar 28, 2012 7:52 PM, John Rose john.r.r...@oracle.com wrote:
http://cr.openjdk.java.net/~jrose/7127687/webrev.00/
7127687: MethodType leaks memory due to interning
Summary: Replace internTable with a weak-reference
http://cr.openjdk.java.net/~jrose/7153157/webrev.00/
7153157: ClassValue.get does not return if computeValue calls remove
Summary: Track intermediate states more precisely, according to spec.
This is a point fix for JDK 8. Here is some more context (from 3/11):
http://cr.openjdk.java.net/~jrose/7129034/webrev.00/
7129034: VM crash with a field setter method with a filterArguments
Summary: add null checks before unsafe calls that take a variable base
reference; update unit tests
This is a point fix for JDK 8, and will also be back-ported to JDK 7u.
—
I just (last night) updated the patches to rebase to the latest
hsx/hotspot-comp/*.
There was a conflicting change in globals.hpp around the white-box test
variable.
So I think there may be stale files in your build environment.
— John
On Mar 27, 2012, at 9:43 AM, Stephen Bannasch wrote:
My
On Mar 11, 2012, at 9:45 AM, Rémi Forax wrote:
Last week, Fredrik found that I've forgotten to implement ClassValue
in the backport of jsr292.
While struggling to implement it, I've found a bug in the implementation
of the JDK. This snippet creates an infinite loop :(
Folks, you probably noticed that I pushed some patches called
macosx-7113349.patch.
These are a preview of Michael McMahon's excellent and much-needed work
transferring macosx build support to JDK8.
With these changes, it is possible to build again on macosx. (Those who build
on Mac have
On Mar 3, 2012, at 4:53 PM, Stephen Bannasch wrote:
I cloned the forest http://hg.openjdk.java.net/jdk8/tl/ into sources
No, we moved to http://hg.openjdk.java.net/hsx/hotspot-comp a while ago. See:
http://hg.openjdk.java.net/mlvm/mlvm/file/tip/README.txt
Regarding step 3: Add Michael's
On Mar 3, 2012, at 7:48 PM, Stephen Bannasch wrote:
Trying with the hsx/hotspot-comp forest I don't get nearly as far:
The messages about unknown node mean that your rm -rf did not succeed, or
that in some other way there are stale .hg/patches/status files floating around
from previous
On Feb 23, 2012, at 3:28 PM, Charles Oliver Nutter wrote:
I just started getting this after fixing a separate bug and attempting
to get JRuby's indy mode green again:
[junit] Java::JavaLang::LinkageError: loader constraint violation:
It looks as if you are loading the anonymous class
On Feb 16, 2012, at 8:43 PM, Mark Roos wrote:
The key code is below and it shows the power of methodHandles is ways one may
not expect. And it
added almost nothing to the run time ( maybe a few %). It inserts itself
into each callsite target and
collect entry and exit data.
Nice!
As
On Jan 23, 2012, at 11:26 PM, Charles Oliver Nutter wrote:
Oh, that does seem to work...what an ugly hack. And actually, you can
just use Object.class but cast the resulting return to void, and it
works.
So basically, I do this:
handler = MethodHandles.constant(Object.class, null)
On Jan 6, 2012, at 4:57 AM, Jochen Theodorou wrote:
I see where it comes from, but reusing that instead of making a new if
is not really needed, is it?
Do people here agree this should be improved?
The javadoc for this throw is:
* @throws IllegalArgumentException if the target does
On Dec 8, 2011, at 1:55 AM, Florian Weimer wrote:
* John Rose:
But, in order to respect the general aim you are mentioning, I have
unhoisted one of the two words from the Class instance itself. This
will cause a minor slowdown in JSR 292 use cases.
What about using ClassValue
either under a per-class lock or during GC (nulling
of weak references).
Could I have a re-review?
Thanks,
-- John
On Sep 20, 2011, at 4:10 PM, John Rose wrote:
On Sep 19, 2011, at 2:58 PM, John Rose wrote:
http://cr.openjdk.java.net/~jrose/7030453/webrev.00
After some comments from
Recent changes in hsx/hotspot have destabilized the build on mac. I just
pushed another workaround here:
http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/mac-tweaks.patch
The buildtree.make change fixes the failure Henri saw. (Or you can add
ALWAYS_PASS_TEST_GAMMA=true to the build
This, I think, is due to some roughness in the makefiles. The integration of
BSD with the JDK8 source base is new and needs more work. The pathname hacking
(for universal binaries) is not right yet.
I get this particular problem on my Macbook, but it's not the only problem:
Thanks Stephen, for the build and the quality report.
BTW, I'm working on simplifying method handle internals and will post a WIP
patch soon.
-- John
On Oct 22, 2011, at 8:59 PM, Stephen Bannasch wrote:
I've uploaded a new mlvm build from today:
I don't know the ins and outs of asm and grabbing rsp on Mac, but the OS X port
group probably know something about it. -- John
On Oct 15, 2011, at 8:49 AM, Michael Barker wrote:
Good luck!
Thanks. I found where the problem is, it's in the
os::current_stack_pointer method in os_bsd_x86.cpp
On Oct 10, 2011, at 7:12 AM, Douglas Campos wrote:
Hello mlvm friends, just a heads up that dyn.js is released at
https://github.com/dynjs/dyn.js
feedback is more than welcome :)
Congratulations on getting this working...
Nice, crunchy uses of invokedynamic, ASM, ANTLR, and dynalang.
On Oct 10, 2011, at 6:48 PM, Krystal Mok wrote:
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)
It's not derivative, and not very surprising to me: I took over JSR 292 from
Gilad after
I just posted the updated version of your patch. Thanks for the contribution.
You might be interested in looking at the tagu.patch I posted (which is a WIP).
It shows, roughly, where the cut points have to be for GC support for a new
data type.
Best wishes,
-- John
On Jul 24, 2011, at 1:58
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
On Sep 18, 2011, at 1:30 PM, Michael Barker wrote:
I've been trying to run a debug build on Mac OS, the normal build
works fine, but the debug version fails with an Illegal Instruction.
I've run it through gdb (output below), but I not sure how accurate
the information is. I think that it's
On Sep 20, 2011, at 1:02 AM, Christian Thalinger wrote:
On Sep 19, 2011, at 11:58 PM, John Rose wrote:
http://cr.openjdk.java.net/~jrose/7030453/webrev.00
src/share/classes/java/lang/ClassValue.java:
233 /** Value stream for for hashCodeForCache. See similar structure
On Sep 19, 2011, at 2:58 PM, John Rose wrote:
http://cr.openjdk.java.net/~jrose/7030453/webrev.00
After some comments from David Holmes (thanks David!) I added internal comments
about race conditions.
I refreshed the webrev with the additional comments. I also changed one
variable
On Sep 19, 2011, at 12:57 AM, Christian Thalinger wrote:
On Sep 18, 2011, at 7:16 PM, Mark Roos wrote:
In looking at my code.
In general 98% of the callsites are 3 targets.
Those that are larger I can catch and use a different lookup. I also
believe that Charles Nutter limits his
http://cr.openjdk.java.net/~jrose/7030453/webrev.00
The existing JDK 7 implementation of ClassValue is a place-holder which is
defective in several ways:
- It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to
values, which is slow.
- It does not lock the root WeakHashMap,
7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init
http://cr.openjdk.java.net/~jrose/7077803/webrev.00
Remove access checking and access narrowing logic from MethodHandles.unreflectX
calls, if isAccessible is true.
-- John
On Sep 19, 2011, at 7:00 PM, Krystal Mok wrote:
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
On Sep 14, 2011, at 3:05 PM, Thomas Wuerthinger wrote:
But one could maybe disable the local variable liveness maps
for the methods that use this functionality (i.e., the extended
exception stack trace or the getLocalArray)?
Yes, of course. But this will increase spilling throughout those
On Sep 11, 2011, at 5:14 PM, Mark Roos wrote:
Where would I look for the features being added? In general is there a place
where pending
changes are listed? One of the 'bug' lists perhaps.
Nothing new here: The new classfile features are those in JDK 7 (JSR 292):
the invokedynamic
On Sep 12, 2011, at 10:23 AM, Thomas Wuerthinger wrote:
If this special exception class is declared as a checked exception, a method
would itself chose if its stack is exposed or not based on its throws
clause. I think in that case the possible exploitations are less than
reflection
On Sep 11, 2011, at 1:10 AM, Michael Barker wrote:
Please give it a whirl and let me know what breaks.
I have a working build on Mac OS X Lion with gcc-4.2. I started with
stephenb's MLVM build scripts.
Excellent work.
Did you have to use patches/hotspot/snowleopard.patch for gcc-4.2, or
On Sep 8, 2011, at 4:57 AM, Thomas Wuerthinger wrote:
Why not the following code pattern? Does it generate too many bytecodes?
That's a reasonable alternative.
It generates data movement bytecodes O(L * M), where L is the average number of
live values at deopt points and M is the number of
On Sep 8, 2011, at 4:06 PM, Thomas Wuerthinger wrote:
Here an example for a scripting method that performs a+b and is guessed to
not overflow.
Your example is simplified by the fact that, in the handler, there is only one
possible deopt point. What if there are two?
E.g., what if your code
On Sep 8, 2011, at 3:06 PM, Rémi Forax wrote:
but you can get live value unless you allow to insert live values to the
constant pool
when linking the class (another old dream).
Can we make a solution from ClassValue? -- John
___
mlvm-dev mailing
On Sep 8, 2011, at 5:35 PM, Thomas Wuerthinger wrote:
The operand stack and locals manipulation in the generated bytecodes must
exactly match the manipulations done by the scripting interpreter, but I
think that it is possible to align those (although there might be some
complexity due to
On Sep 7, 2011, at 12:00 AM, Per Bothner wrote:
I assume this is one reason why Kawa's IntNum is (mostly) faster than
BigInteger.
Yes, that's probably true.
Here's a dirty secret: As you can see from the OpenJDK sources, BigDecimal,
but not BigInteger, has this optimization (see private
On Sep 7, 2011, at 7:24 AM, Rémi Forax wrote:
so the VM knows that only methods *DetectingOverflow are able to throw that
specific exception.
int addDetectingOverflow(int x, int y) throws IntegerOverflowException
This also have the advantage that the inlining heuristic can be tweaked
to not
On Sep 7, 2011, at 12:33 PM, Thomas Wuerthinger wrote:
This would probably also mean that the exception object created for capturing
the slow-case program state needs to be escape-analyzed and removed in the
optimized code that deoptimizes on overflow?
Yes. And in the case of user-defined
On Sep 7, 2011, at 3:28 PM, Rémi Forax wrote:
On 09/07/2011 10:38 PM, John Rose wrote:
Object l0, l1, l2, ...;
l0 = l1 = l2 = ... null; // these are required only for definite
assignment in the catch body
try {
...do fast path...
if (...constraint violated...) throw new
On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote:
Did we ever figure out if it's possible to trick Hotspot into doing a
JO instead of the raw bit-level operations? John/Christian/Tom: what
would it take to get HS to know that we're doing an integer
overflow-after-maths check and do the
On Sep 6, 2011, at 12:58 PM, John Rose wrote:
What's needed here is a way to get 33 bits out of a 32-bit add intrinsic.
There's no fully natural way to do this, and about 4 kludgey ways. Because
there are so many poor ways to shape the API, it's hard to pick the best one
to invest
OK, I have rebased the mlvm patch repository to hsx/hotspot-comp.
If you have been reusing your upstream source repositories (based on bsd-port),
you will have to discard them and pull instead from hotspot-comp.
As a temporary solution for building on Mac OS, I have included a set of new
On Sep 2, 2011, at 5:07 AM, Stephen Bannasch wrote:
is gcc 4.0 still required.
That requirement hasn't changed. I don't think anyone has retried 4.2 recently.
I removed the bsd-port forest in sources and ran:
hg fclone http://hg.openjdk.java.net/hsx/hotspot-comp sources
Re-created the
On Aug 25, 2011, at 11:23 PM, Jeroen Frijters wrote:
I was surprised by this as well (from an implementers point of view), because
the use of asType is an implementation detail. Normally when you call a
method taking a boolean/byte/short/char you also load an int onto the stack,
so why
That's a good suggestion; thanks. -- John
On Aug 25, 2011, at 11:06 AM, Rémi Forax wrote:
Hi John, hi all,
several people (2 actually :) ask me how to use a boolean/byte/short/char
as a bootstrap argument.
As you know, you can't because you can't encode a constant
On Aug 19, 2011, at 9:15 PM, Mark Roos wrote:
The end fallback/lookup is synchronized and so there is only one update at a
time, but the
new GWT is added to the start of the chain and the second thread is past that
point. So
when the second gets to the fallback it still thinks the
On Aug 11, 2011, at 3:01 PM, Rémi Forax wrote:
Yes, you can have duplicate GWTs and
I'm also interested if someone find a better approach :)
You can use a custom subclass of MutableCallSite which synchronizes its updates.
That way two racing threads cannot install duplicate case-handling
## Using an interface as a marker for dynamically typed reference
1. Take one fresh interface D. Remove all methods.
2. Sprinkle D freely in invokedynamic signatures, wherever a static type
dynamic is desired.
3. When binding a MH to such an interface, retype MH in two steps, an asType
and an
On Aug 2, 2011, at 6:44 PM, Mark Roos wrote:
We are using the JVMTI api FollowReferences to collect object information.
In this
api we can set a klass which limits the objects reported. For some reason we
get instances of the
klass we set and BoundMethodHandle instances.
Hi Mark.
Your proposal looks right, at least until JVMTI has native support for MH
interposition.
It might be more efficient to use a SwitchPoint to enable the slow path
testing. Basically, the switchpoint would take the place of the GWT, and (when
invalidated) would execute a slow path that
On Jul 9, 2011, at 7:13 AM, Alexander Turner wrote:
I am Alex Turner - I was working on a COBOL to JVM compiler and am now
helping with a Magik to JVM compiler. I thought I might just confirm
that invokeExact has proven a lt ot quicker than invoke in our tests.
We have also noticed that using
Yes, please. We especially love stress tests.
-- John (on my iPhone)
On Jun 30, 2011, at 12:51 PM, Mark Roos mr...@roos.com wrote:
I'll have Oscar run the patch check for you. And we are now able to pack it
up as a jar (finally) so we can get
the test case to you if you would like.
Do you have a website or blog you can post it on?
On Jun 30, 2011, at 8:47 PM, Mark Roos wrote:
John requested
Yes, please. We especially love stress tests.
Oscar is putting it together. Where should we put/send it ( its not very
large)
regards
That looks like bug 7056328, or its twin. Please check if you are using a JVM
with that fix included.
Possible workaround: Put your RT on -Xbootclasspath.
-- John
On Jun 29, 2011, at 6:41 PM, Mark Roos wrote:
I have been loading the jvm using a recursive Hanoi and am seeing random
errors
The Proposed Final Draft for JSR 292 is now posted. It is a part of the JDK 7
umbrella JSR, JSR 336.
http://jcp.org/aboutJava/communityprocess/pfd/jsr292/index.html
The landing page lists the interactions with the JVMS and JLS.
You may be surprised to find that this version of the
On Jun 22, 2011, at 6:51 AM, Ola Bini wrote:
On 2011-06-21 00.23, John Rose wrote:
I have pushed a possible fix for 7056328 to the mlvm queue. This bug
includes Ola's mysterious class not found failure.
292-users (Charlie, Ola): Please give it a whirl, to find rough edges, etc.
292
On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
Sorry, I was thinking recording which branch of the GWT is taken and
storing them in the GWT.
Two GWTs should not share the same metadata.
This is the major problem with GWT/selectAlternative. Previously when GWT
was bytecodes we at
On Jun 13, 2011, at 8:37 AM, Ola Bini wrote:
On 2011-06-13 10.14, Ola Bini wrote:
I did a rebuild of MLVM+bsdport today, and I now see the missing class
crash again on my Mac too (to clarify, this was gone from my Mac for a
while, but came back. This means it's consistent with my JDK7 build
Charlie, thanks for being our Chief Test Victim Subject on performance issues.
I have a question for you (and for the list in general).
Since 6/03 the following patch in the mlvm queue has set GWT to use ricochet
frames by default:
On Jun 14, 2011, at 5:21 PM, Attila Szegedi wrote:
Thanks for the clarification, John. I'll go with asFixedArity().
Great! BTW, this little method got into the API by the skin of its teeth.
Here's an interesting related exercise: If I have a variable-arity method
handle (like
On Jun 11, 2011, at 2:18 PM, Attila Szegedi wrote:
And BTW, attempts at using invoke() or invokeExact() didn't work either… They
all behave strangely. What's the sanctioned way to pass an array explicitly
as a vararg argument?
See the updated example below. The javadoc for
On Jun 11, 2011, at 1:31 PM, Ola Bini wrote:
Asking here too: is that still happening? -- Christian
I haven't seen any commits that is likely to fix it, but I will rebuild
and take a look today.
The commits for 7047697 and 7052202 both fix crashes.
-- John
On Jun 10, 2011, at 4:39 PM, Charles Oliver Nutter wrote:
Please tell me I'm wrong, or tell me that we can modify catchException
in some way to also allow post-processing of non-exceptional results
(with return value inserted where the Throwable would go)!
I think this does what you want:
On Jun 9, 2011, at 2:46 PM, Stephen Bannasch wrote:
On Jun 9, 2011, at 12:55 PM, Stephen Bannasch wrote:
-XX:+EnableInvokeDynamic -XX:-UseRicochetFrames
These flags are now obsolete. I suggest testing without them. -- John
Thanks, that fixed the tests -- all jdk/test/java/lang/invoke
On Jun 7, 2011, at 3:38 PM, Charles Oliver Nutter wrote:
So I figured I'd check assembly output, and I was surprised to see a
callq right where I expect to see the literal. Are
MethodHandle.constant handles not inlined right now?
Here is what constant(Object.class, foo) reduces to:
a serious
crash in the machinery too... Have you seen any reason why that
happens?
Cheers
On 2011-05-24 06.11, John Rose wrote:
On May 23, 2011, at 3:44 PM, Tom Rodriguez wrote:
I'd *love* for intermediate static Java snippits like this
to inline straight through, even if invokeExact would
On Jun 3, 2011, at 11:47 PM, John Rose wrote:
On Jun 3, 2011, at 7:07 AM, Ola Bini wrote:
Is there anything I can do to help out with finding this problem?
I can't reproduce the VM crash yet. Like Christian, I got through problems 1
and 2, on bsd (both 32-bit and 64-bit).
Problem 3
On Jun 3, 2011, at 4:15 PM, Tom Rodriguez wrote:
On Jun 2, 2011, at 7:37 PM, John Rose wrote:
Thanks; I'll look at your dump later tonight.
If the problem is friction from interface casts, we can probably remove
them. It's hard to figure out how they are getting in, though. It happens
On Jun 3, 2011, at 10:22 AM, Y. Srinivas Ramakrishna wrote:
Looks good. Thanks for caring for the unwary user (which i unwittingly
represented when i previously pointed out the admittedly somewhat
subjective naturalness of the stable negative sense compared with
the unstable positive sense).
And, thanks for the code review, Ramki, Vladimir, and Tom. -- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On Jun 3, 2011, at 11:58 AM, Rémi Forax wrote:
This means that you need one MDO by method handle (which do a call) by
callsite associated to an invokedynamic.
As far as I know, hotspot doesn't do that.
You are right. There are paths like that which escape call-site profiling.
There's no
On Jun 2, 2011, at 9:01 AM, Charles Oliver Nutter wrote:
Ok, the ricochet flag performs in the expected range...but still
slower than the old logic, and also slower than the 5/13 macosx build.
You mean java -Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=true?
If so, let's look at the code
Optimizations can go into any release.
-- John (on my iPhone)
On Jun 2, 2011, at 9:43 AM, Thomas E Enebo tom.en...@gmail.com wrote:
Out of curiousity...How tough is it to get new optimizations into
u{1-n} releases?
___
mlvm-dev mailing list
Thanks; I'll look at your dump later tonight.
If the problem is friction from interface casts, we can probably remove them.
It's hard to figure out how they are getting in, though. It happens when
IRubyObject interconverts with Object. Are you doing it, or is it coming from
inside the
On Jun 1, 2011, at 1:37 PM, Tom Rodriguez wrote:
I'm seeing slow perf as well but I think it might be a jruby/292 mismatch
problem:
Yes; the 292 expert group yanked convertArgs since it was a near-synonym of
asType. (The delta is factored into the new method asFixedArity.)
The mlvm patch
On Jun 1, 2011, at 6:11 PM, John Rose wrote:
I'll spin a meth.jar that includes (a) recent fixes and (b) deprecated
methods. (Actually, two meth.jar's.)
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/meth.jar
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/meth
On May 31, 2011, at 9:36 AM, Charles Oliver Nutter wrote:
If you mean java.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=true, then I
have more bad news...it's even slower :(
Is that with meth-bim.patch applied? That is Tom's first cut at an
optimization for RFs.
-- John
On May 26, 2011, at 11:38 PM, Ola Bini wrote:
It seems there is still a difference in how asType MHs work between what
is in current JDK7 repo, and what you get from building bsdport with
mlvm patches. Specifically, when running things with bsdport/mlvm they
work. When running on JDK7 (built
On May 27, 2011, at 12:11 AM, Ola Bini wrote:
I ran the compile against what's in b144, but directly from the JDK7 repo
On 2011-05-27 12.26, John Rose wrote:
On May 26, 2011, at 11:38 PM, Ola Bini wrote:
Caused by: java.lang.IllegalArgumentException: target and fallback types
must match
On May 27, 2011, at 12:39 AM, Ola Bini wrote:
invoker(type())
Recheck your assumptions about what invoker returns: That changed. You might
need to adjust:
invoker(type().generic())
or
invoker(type()).asType(...)
Or maybe there's a type.generic() elsewhere that can go away.
-- John
On May 27, 2011, at 8:04 AM, Charles Oliver Nutter wrote:
There's substantially more code here. I don't see any jumps that would
short-circuit this logic. Am I reading right?
Now the good news is that after the test is completed I don't see much
additional logic on MLVM before it's back
Wish all our problems would solve themselves as easily!
-- John (on my iPhone)
On May 27, 2011, at 10:09 PM, Ola Bini ola.b...@gmail.com wrote:
Hi,
I just updated to the latest version of bsdport+mlvm-coro. It seems that
the latest merge has removed all the breakages I was experiencing.
On May 25, 2011, at 11:04 PM, Charles Oliver Nutter wrote:
I don't say it's not clever. It's just not something anyone is
typically going to figure out on their own. There will be constant
questions if I can invalidate a SwitchPoint, why can't I ask if it
has been invalidated?
You are right
become
* invalid before the querying thread begins to act on the
* supposed validity.
* @return true if this switchpoint has never been invalidated
*/
public boolean isValid() {
return (mcs.getTarget() == K_true);
}
tom
On May 25, 2011, at 3:30 AM, John Rose
On May 26, 2011, at 12:15 AM, Charles Oliver Nutter wrote:
It is definitely frustrating to see that perf has degraded so much the
past couple weeks and still not be there with the reverted code.
I second that.
I did some more cherry-picking this evening and the mlvm patch queue is now
closer
On May 26, 2011, at 1:42 AM, Christian Thalinger wrote:
Using Tom's new code doesn't make a difference since I think the meth.jar
from John includes the reverted GWT code.
I just added a hook to test whether the GWT change matters or not. Choose
either flag setting:
java
On May 26, 2011, at 2:12 AM, Ola Bini wrote:
Hey John,
Something in the patch queue fails to apply cleanly:
That was quick! I noticed that when I spun the meth.jar. Fixed! -- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
On May 26, 2011, at 3:02 AM, Rémi Forax wrote:
...which pretty much
describes all concurrently mutable state, doesn't it? ;)
You're right :)
- Charlie
Rémi
Caught me. :-) That didn't take long. -- John
___
mlvm-dev mailing list
Invalidity is stable because it is permanent.
-- John (on my iPhone)
On May 26, 2011, at 12:10 PM, Y. S. Ramakrishna y.s.ramakris...@oracle.com
wrote:
John, you state that validity is not a stable property.
Is invalidity a stable property, or not even that is.
On May 26, 2011, at 1:21 PM, Charles Oliver Nutter wrote:
isInvalid seems a bit double-negativy to me.
That's my hesitation. Consider the use case:
void maybeCleanUpMess(SwitchPoint sp) {
if (!mysp.isInvalid()) return;
... // do cleanup after invalidation
}
It reads better as:
On May 26, 2011, at 2:43 PM, Charles Oliver Nutter wrote:
Hmm, I'll look into it. I used the amd64 build from the hsdis project
I posted the bsd/amd64 libdis when I was desperate for something that would at
least link and partially decode instructions. But that hsdis binary doesn't
really
On May 26, 2011, at 3:45 PM, Charles Oliver Nutter wrote:
Ahh...well is there another binary you can point me at? Otherwise,
I'll just do i386 asm for now.
I tagged it. It's broken in the sense that it's a brutal 64-bit build of code
designed only for 32-bit disassembly.
I suggest doing at
On May 26, 2011, at 10:11 AM, Tom Rodriguez wrote:
isValid looks fine.
Thanks Tom. I also corrected the javadoc, added a demo of isValid and copied
the javadoc example into the unit tests.
-- John
diff --git a/src/share/classes/java/lang/invoke/SwitchPoint.java
On May 26, 2011, at 4:53 PM, Charles Oliver Nutter wrote:
On Thu, May 26, 2011 at 5:20 AM, Rémi Forax fo...@univ-mlv.fr wrote:
As far as I know there is no specific optimization of SwitchPoint
i.e there is still a volatile read in the middle of the pattern.
If that's true I'm not sure how
201 - 300 of 706 matches
Mail list logo
