After wasting a lot of time investigating why one of my Model classes was not instrumented anymore, I realized this line of code, from a static method I added to my Model, was the culprit:
// myObjects is a List<SomeModel>
myObjects.forEach((SomeModel m) -> System.out.println(m.getId()));
Why?
Thanks.
You might have stumbled on a bug. Please, file an issue here: https://github.com/javalite/activejdbc/issues and provide as much detail on how to reproduce as you can.
Related
Does anyone know whether the Cog VM for Pharo and Squeak is able to optimize away simple indirect variable accesses with accessors like this:
SomeClass>>someProperty
^ someProperty
SomeClass>>someSecondProperty
^ someSecondProperty
that just return an instance variable, so that methods like this:
SomeClass>>someMethod
^ self someProperty doWith: self someSecondProperty
will be no slower than methods like this:
SomeClass>>someMethod
^ someProperty doWith: someSecondProperty
I did some benchmarks, and they do seem roughly equivalent in speed, but I'm curious if anyone familiar with Cog knows for certain, because if there is a difference (no matter how slight), then there might be situations however rare where one is inappropriate.
There's a little cost right now but it's so little that you should not bother. If you want performance, you are willing to change other parts of your code, not instance variable access.
A quick bench:
bench
^ { [ iv yourself ] bench . [ self iv yourself ] bench }
=> #('52,400,000 per second.' '49,800,000 per second.')
The difference does not look so big.
Once jitted and executed once, the difference is that "self iv" executes an inline cache check, a cpu call and a cpu return in addition of fetching the instance variable value. The call and return instructions are most probably going to be anticipated by the cpu and not really executed. So it's about the inline cache check which is a very cheap operation.
What the inlining compiler in development will add is that the cpu call and return are really going to be removed with inlining, which will cover the cases where the cpu has not anticipated them. In addition, the inline cache check may or may not be removed depending on circumstances.
There are details such as the getter method needs to be compiled to native code which takes room in the machine code zone which could increase the number of machine code zone garbage collection, but that's even more anecdotic than the inline cache check overhead.
So in short, there is a very very very little overhead right now but that overhead will decrease in the future.
Clement
This is a tough question... And I don't know the exact answer. But I can help you learning how to check by yourself with a few clues.
You'll need to load the VMMaker package in an image. In Pharo, there is a procedure to build such image by just downloading everything from the net and github. See https://github.com/pharo-project/pharo-vm
Then the main hint is that methods that just return an instance variable are compiled as if executing primitive 264 + inst var offset... (for example, you'll see this by inspecting Interval>>#first or any other simple inst var getter)
In classical interpreter VM, this is handled in Interpreter>>internalExecuteNewMethod.
It seems like you pay the cost of a method lookup (some caches make this cheaper), but not of a real method activation.
I suppose that it explains that debuggers can't enter into such simple methods... This however is not a real inlining.
In COG, the same happens in StackInterpreter>>internalQuickPrimitiveResponse if ever interpreter is used.
As for the JIT, this is handled by Cogit>>compilePrimitive, see also implementors of genQuickReturnInstVar. This is not proper inlining either, but you can see that there are very few instructions generated. Again, I bet you generally don't pay the price of a lookup thank to so called Polymorphic Inline Cache (PIC).
For real inlining, I didn't find a clue after this quick browsing of source code...
My understanding is that it will happen at image side thru callback from Sista VM, but this is work in progress and only my vague recollection. Clement Bera is writing a blog about this (the sista chronicles at http://clementbera.wordpress.com)
If you're afraid of digging in VMMaker source code, I invite you to ask on vm-dev.lists.squeakfoundation.org I'm pretty sure Eliot Miranda or Clement will be happy to give you a far more accurate answer.
EDIT
I forgot to tell you about the conclusion of above perigrinations: I think that there will be a very small difference if you directly use the inst. var. rather than a getter, but this shouldn't be really noticeable, and in all cases, your programming style should NOT be guided by such neglectable optimizations.
I'm having a problem.
I'm using a code in a testCase
It starts like this
|mapeos obj myClass|
myClass := Smalltalk at: #ClaseForTesting.
myClass addToComposition: TraitPruebaCondicion1.
the #ClaseForTesting is an emptyClass
when smalltalk do
myClass addToComposition: TraitPruebaCondicion1
if I (Debugging) try to get the traits
myClass traits
I'm getting
an OrderedCollection(AnObsoleteTraitPruebaCondicion1)
why is adding AnObsolete in the string trait name?
If I run the same code in workspace, it works really fine.
Why is this happening? any ideas?
Please, its urgent :(
I can't believe that I was stuck with this a lot of time, and then when I FINALLY decided to ask to the people, I've solve it in two minutes. Shame on me. It must be some kind of mystical brainstorming with this site.
Anyway, the clue was to using
Smalltalk at: #
with the trait too! (I was only using it on the class)
so
myClass addToComposition:(Smalltalk at: #TraitPruebaCondicion1).
solve my problem.
I've just started using RestKit, and got an issue when trying to create RKObject subclass; apparently, such class is not found, but this example http://mobile.tutsplus.com/tutorials/iphone/restkit_ios-sdk/ shows how to make it. I installed it and it seems to be working ok.
So I am wondering whether that class was removed and there is an alternative or am I doing something wrong here?
Yes, RKObject was removed. Here is an answer to the same question.
I ran into strange problem. I have the whole domain model defined in the orm.xml file. All my entities in my project are just simple POJOs (no jpa annotations at all). I want to save the last update and the insert timestamps of my entities and I've decided to use the "pre persist" and "pre update" like most of us. So I've defined a base entity class and let all my entities to extend it.
Strange is that the "pre persist" (and all others events) are being called only when I define them using annotations. When I define them in the orm.xml file instead - nothing happens, they are just ignored.
This works for me:
public abstract class BaseEntity {
private Timestamp insertTimestamp;
private Timestamp lastUpdateTimestamp;
#PrePersist
public void onPersist() {
...
}
#PreUpdate
public void onUpdate() {
...
}
}
But after removing annotations and switching to the xml nothing works anymore:
<mapped-superclass class="com.my.model.BaseEntity">
<pre-persist method-name="onPersist"/>
<pre-update method-name="onUpdate"/>
<post-load method-name="postLoad"/>
</mapped-superclass>
According to the JPA specification the above declarations in xml seem to be correct.
I have no idea where to dig for the problem.
I'm using EclipseLink 2.2.0 with H2 in the SE environment.
UPDATE:
Thanks for your answer. There are no errors in log/console to see. Events just seem being ignored.
As you thought is might be a bug because moving the methods and XML declarations from the superclass to the subclass solves the problem. It is not a desired solution for me as I want to have a global solution for all entities but moved me a bit forward.
I've sent the bug report to the EclipseLink guys :)
As you suggested I've tried with entity listener and it works for me. so I will stick to this solution. It even looks better then the solution with base entity class ;)
Thanks !
Your XML looks correct. Do any errors occur in the logs?
It could be a bug with MappedSuperClass and entity events.
Can you try setting the event on a subclass and see if it works?
If it does, then it is probably a bug, please log the bug in Eclipse Bugzilla.
Another workaround would be to use an entity listener.
I mean the fundamental runtime. How is method dispatching implemented (via a selector hashtable?). What is a selector anyway? How is the object model as you can add methods later with some low level API etc.
I need to look at it from a compiler programming point of view, not a simple user of the language.
Use the source.
http://www.opensource.apple.com/source/objc4/objc4-437/
And for parsing, look to Clang:
http://clang.llvm.org/get_started.html
Here's a few docs to get you started (should help you google the right questions):
http://www.mulle-kybernetik.com/artikel/Optimization/opti-9.html
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/index.html